BRPI0621455A2 - sistema e métodos de autenticação de usuário e implementado por servidor - Google Patents
sistema e métodos de autenticação de usuário e implementado por servidor Download PDFInfo
- Publication number
- BRPI0621455A2 BRPI0621455A2 BRPI0621455-0A BRPI0621455A BRPI0621455A2 BR PI0621455 A2 BRPI0621455 A2 BR PI0621455A2 BR PI0621455 A BRPI0621455 A BR PI0621455A BR PI0621455 A2 BRPI0621455 A2 BR PI0621455A2
- Authority
- BR
- Brazil
- Prior art keywords
- user
- server
- key
- password
- applet
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2119—Authenticating web pages, e.g. with suspicious links
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Information Transfer Between Computers (AREA)
- Storage Device Security (AREA)
Abstract
SISTEMA E MéTODOS DE AUTENTICAçãO DE USUáRIO E IMPLEMENTADO POR SERVIDOR. DigiPass para a Web proporciona segurança para comunicação de internet maior do que aquela alcançada pelo uso de uma contra-senha estática sem exigir que o usuário instale qualquer software ou possua ou use hardware dedicado de nenhum tipo. O usuário acessa meramente um sitio da web apropriado que baixa um applet para o navegador do usuário. Isto é uma função convencional que é manuseada pelo navegador e não exige nenhuma perícia por parte do usuário, O navegador confia numa contra-senha conhecida apenas para o usuário autenticar o usuário para o navegador/appleL O navegador/applet interage com o servidor para criar uma chave de autenticação que é, então, armazenada no computador do usuário, O usuário pode invocar a chave de autenticação dependente da apresentação da contra-senha do usuário para o navegador! applet. Visto que a contrasenha não é usada fora da interação do usuário-navegador! applet, nãoestá sujeita a ataques por hackers. A chave de autenticação também está protegida por criptografia contra ataques, embora o usuário nao precise memorizar nenhumas informações além da contra-senha.
Description
"Sistema e Métodos de Autenticação de Usuário e Implementado por Servidor"
Relatório Descritivo
Campo da Invenção
A invenção relaciona-se com aperfeiçoamentos na segu- rança em redes de computadores.
Antecedentes
Ficou comum e com o passar do tempo muito mais comum que os aplicativos sejam acessados e as transações conduzidas remotamente em redes públicas tais como a internet. A popularidade destes aplicativos atraiu a atenção de hackers e organizações crimino- sos. Para proteger os aplicativos contra acesso sem autorização, muitos provedores de aplicativos confiam em que seus usuários têm de subme- ter, durante o login, a combinação da identificação de usuário [userid) com uma contra-senha. Na maioria dos casos, a contra-senha é estáti- ca, isto é, o mesmo valor de contra-senha permanece válido durante um período relativamente longo de tempo.
Para que os hackers consigam acesso a um aplicativo remoto para tomar parte em transações fraudulentas, é suficiente obter uma combinação válida de userid-contra-senha. Por exemplo, um método popular é enviar correio eletrônico falso solicitando ao usuário (com pretexto mais menos acreditável) que envie a sua userid-contra- senha em resposta. Isto é freqüentemente chamado de phishing. Outro método popular é para criar um sítio impostor da web que se parece convenientemente com o sítio real da web. Obviamente, quando um usuário tentar fazer o login, a sua userid-contra-senha é capturada para uso inadequado mais tarde. Em razão da facilidade com que hackers de sucesso alcançaram a combinação válida de userid-contra-senha, é agora extensamente aceito que uma contra-senha estática oferece apenas um nível de segurança muito baixo para que seja aceitável para aplicativos que envolvem transações financeiramente valiosas e similares. Em conseqüência, existe uma necessidade de um método alternativo de autenticação de usuário que ofereça um nível de segurança mais eleva- do.
Existem técnicas alternativas. Estas incluem:
1 - Certificados (isto é, software, em smartcards ou fichas de USB);
2 - Fichas de hardware de autenticação forte;
3 - Fichas suaves (isto é, fichas de software de emulação de hardware autenticação forte);
4 - Cartões inteligentes;
5 - Fichas de USB.
Na maioria dos casos, os usuários têm de estar equipa- dos com um dispositivo de hardware personalizado (fichas de USB, fichas de autenticação forte, cartões inteligentes etc...) ou devem insta- lar alguma peça personalizada de software (certificados de software, fichas suaves etc...). A desvantagem principal destas soluções, quando comparadas com o método ordinário da userid-contra-senha, é que:
(a) são mais caros (em razão do hardware específi- co que é exigido para implementá-los) ou
(b) limitam a mobilidade do usuário a um compu- tador específico (em particular, o computador em que foi instalado o hardware ou o software personalizado) ou
(c) não são fáceis de usar (o usuário precisa seguir um procedimento de instalação complicado que poderia falhar) ou
(d) uma combinação das desvantagens preceden- tes.
Em conseqüência, o que é necessário é uma solução que proporcione maior segurança do a userid-contra-senha, mas ainda retenha as vantagens principais da userid-contra-senha, isto é, baixo custo, fácil de usar e fácil de migrar de um computador para outro.
Tipicamente, os usuários usam um computador, como um computador pessoal (PC) para acessar aplicativos num servidor remoto. Todavia, também são usados outros dispositivos diferentes de PC é, isto é, dispositivos móveis como um assistente de dados pessoais (PDA) e telefones celulares habilitados para web e semelhantes. Para os propósitos deste aplicativo, o termo computador pessoal ou PC deve incluir todo esses dispositivos assim como também outros dispositivos semelhantes que possam acessar através da Internet um dispositivo de internet remoto, tal como um servidor, e permutar informações e men- sagens por meio de um software de navegador, quer esse acesso seja via uma linha terrestre ou inclua um componente sem fio.
Sumário da Invenção
O Digipass para solução de Web é baseado nos seguintes princípios:
a - Para cada usuário, um servidor associa o usuário a uma chave de autenticação.
b - A chave de autenticação associada a um usuário específico também está localmente armazenada num computa- dor pessoal na forma de um cookie.
c-A chave de autenticação armazenada do usuário no cookie é protegida por uma contra-senha conhecida apenas do usuário.
d - O login da página da Web do servidor contém um applet de autenticação embutido (isto é, um componente de softwa- re que pode ser referenciado e chamado numa página da Web e é automaticamente baixado pelo navegador, se não estiver já presente no acesso do computador pessoal). O applet é, de preferência, um Java Applet, mas, alternativamente, poderia também ser, por exemplo, um componente ActiveX.
e - O applet de autenticação pode solicitar que um usuário entre com a contra-senha.
f - O applet de autenticação pode acessar o cookie que armazena a chave de autenticação protegida pela contra-senha. O applet pode obter acesso à chave de autenticação com a contra-senha com que o usuário entrou.
g - Usando a chave de autenticação acessível (associada no servidor ao usuário específico), o applet de autenticação pode autenticar o usuário ou assinar dados de transação para garantir a autenticidade e a integridade da transação.
Em virtude destes princípios, o a solução DigiPass para a Web alcança segurança mais elevada do que meramente uma contra- senha estática: para autenticação bem sucedida, dois fatores são necessários, isto é, o cookie (que contém a chave de autenticação) e a contra-senha do usuário (a fim de decifrar a chave de autenticação que está armazenada no cookie). A solução DigiPass para a Web proporcio- na uma solução de custo efetivo na medida em que não existe nenhum hardware para distribuir e o único software que é necessário (o applet de autenticação) é automaticamente baixado, quando exigido. A solu- ção DigiPass para a Web também proporciona conveniência para o usuário na medida em que o usuário não tem de fazer nenhum proces- so de instalação particular que pudesse falhar e que o usuário opera a solução exatamente do mesmo modo que com uma contra-senha estáti- ca, isto é, o usuário só tem que entrar em uma contra-senha (isto é, o mecanismo de autenticação dinâmica é completamente transparente para o usuário). Isto resulta do fato de que tudo o que é exigido pela solução é funcionalidade de navegador normal ou é proporcionado num applet que é automaticamente baixado pelo navegador.
Em alguns casos (tal como no primeiro uso do applet), quando o applet é usado por um usuário específico, ao usuário é pedido que escolha e introduza um segredo de migração. O segredo de migra- is ção ou um hash do segredo de migração é transferido com segurança para o servidor. Se, depois disso, o usuário tentar acessar o servidor usando um computador pessoal que não armazene a chave de autenti- cação num cookie, os eventos seguintes desdobrar-se-ão. Ao detectar esta condição o applet de autenticação solicita ao usuário que introduza o segredo de migração, assim como também uma contra-senha. Isto será chamado de uma contra-senha local e pode ser a mesma ou dife- rente da contra-senha usada no PC original. Usando o segredo de migração, o applet pode, então, baixar com segurança uma chave de autenticação (ou a mesma chave de autenticação que é armazenada no cookie no PC normalmente usado pelo usuário ou uma chave de auten- ticação diferente) a partir do servidor e, então, armazena localmente a chave de autenticação baixada num cookie no PC, atualmente emprega- do pelo usuário [FCO: de alguma maneira não devíamos mencionar que a autenticação no cookie no novo PC está protegida pela contra-senha que o usuário introduziu junto com o segredo de migração?]. Comesta característica, a solução DigiPass para a Web também proporciona mobilidade, por exemplo, o usuário pode migrar de um PC normalmente usado para um PC diferente, sem ter que planejar com antecedência.
Deve ficar evidente a partir do anteriormente mencionado que tanto o servidor como um PC de usuário mantêm uma chave de autenticação, em uma forma ou outra. Numa modalidade da invenção, é baseada confiança sobre a segurança normal oferecida pela conexão da Internet entre o PC de usuário e o servidor para manter a confiden- cialidade na permuta inicial da chave de autenticação. Por exemplo, o PC do usuário e o servidor poderiam confiar numa conexão de SSL/TLS normal.
Numa modalidade alternativa, o usuário e o servidor compartilham um segredo antes de um contato inicial entre o PC e o servidor. Isto poderia ser o caso se o usuário tivesse sido um usuário com uma userid e contra-senha estática estabelecidas e a intenção fosse migrar o usuário para a solução DigiPass para a Web para propósitos de autenticação. Se o usuário e o servidor compartilham esse segredo histórico (por exemplo, a contra-senha do usuário), então, o segredo pode ser usado para assegurar a permuta inicial entre o usuário e o servidor da chave de autenticação.
Numa modalidade, o segredo histórico (a contra-senha estática existente) pode ser usado de acordo com alguma contra-senha existente baseada num protocolo de permuta de chave de autenticação (por exemplo, protocolo SRP-Secure Remote Password) para proteger a permuta da chave de autenticação secreta.
Noutra modalidade, o usuário e o servidor usam um canal de comunicação diferente da Internet (tal como um correio eletrô- nico, um Banco 24 horas, correio baseado em papel etc.) para permutar diretamente a chave de autenticação ou outro segredo que será, então, usado da mesma maneira que o segredo histórico descrito acima. A chave de autenticação, numa modalidade, é uma chave de criptografia simétrica que é usada tanto no servidor como num PC do usuário. Com chaves de autenticação simétrica, a autenticação do usuário pode ser realizada usando protocolos de autenticação existen- tes baseados em segredos compartilhados tais como o Challenge Hand- shake Authentication Protocol (CHAP).
Numa modalidade alternativa, o applet de autenticação usa uma chave de autenticação compartilhada para emular uma ficha de hardware de autenticação forte. Nesse caso, o applet gera contra- senhas dinâmicas que são calculadas como se segue:
a - O applet toma o valor de uma entrada de variável que é implícita ou explicitamente conhecida do servidor. A entrada de variável poderia ser o tempo atual, um desafio dinamica- mente gerado pelo servidor, o valor de um contador que está localmente armazenado (no mesmo cookie com a chave de autenticação) e incre- mentado automaticamente depois de cada uso ou uma combinação de quaisquer acima.
b - O applet codifica a entrada de variável (con- forme está ou com alguma formatação particular) com a chave de autenticação usando algum algoritmo de criptografia simétrico.
c - O criptograma resultante (conforme está ou depois de alguma formatação e/ou mutilação adicionais) é uma contra- senha dinâmica e é, então, enviado para o servidor.
d - O servidor conhece o valor da entrada de variável e o valor da chave de autenticação associada ao usuário dado. Com estes dados, o servidor realiza os mesmos cálculos para obter o seu próprio valor para a contra-senha dinâmica.
e - O servidor compara o valor da contra-senha dinâmica que gerou com o valor que recebeu do usuário. Se ambos os valores forem os mesmos ou de outra forma comparáveis, então o usuário é considerado como autenticado.
Alternativamente, assinar dados de transação com um segredo compartilhado gerando um Message Authentication Code (Código de Autenticação de Mensagem) (MAC) é prática comum. Um exemplo é descrito no padrão ANSI X9.9. Uma alternativa inclui os dados de transação na entrada de variável para o algoritmo de autenti- cação que foi descrito acima.
Como alternativa, a chave de autenticação pode ser uma parte privada de um par de chave privada-pública. Nesse caso, o servi- dor segura, para cada usuário, a parte da chave pública corresponden- do a uma chave privada associada ao usuário. Usuários de autentica- ção e a assinatura de dados usando um par de chaves pública-privada é uma prática comum que não precisa ser aqui explicada.
Numa modalidade da invenção, a justeza da contra- senha do usuário, introduzida em resposta a um pedido pelo applet, não é localmente validada antes que a chave de autenticação seja decifrada. Ao invés, o applet decifra a chave de autenticação codificada com a contra-senha como fornecida pelo usuário, mas, se o valor da contra-senha fornecida não for correto, o valor da chave de autenticação decifrada também estará incorreto. Em conseqüência, a autenticação falhará. As conseqüências desse fracasso e de repetidos fracassos dependem da configuração do servidor, isto é, se e depois de quantas tentativas a conta do usuário será bloqueada em várias tentativas de autenticação falhadas sucessivas.
Noutra modalidade, a contra-senha pode ser localmente verificada pelo applet antes de ser usada para decifrar a chave de autenticação. Numa modalidade, o cookie não só armazena a chave de autenticação codificada, mas também um hash da contra-senha. Quando o usuário introduzir a contra-senha, o applet calcula o hash da contra-senha e compara-o com o hash armazenado no cookie. Se ambos os valores combinarem, a contra-senha introduzida pelo usuário é correta e o applet continua com a decifração da chave de autentica- ção.
A desvantagem principal da validação local da contra- senha acontece no evento de que um atacante tenha conseguido acesso ao cookie. Esse atacante pode em princípio montar uma busca exausti- va offline. Por outro lado, no caso de validação remota (pelo servidor), o único caminho para validar a contra-senha é tentando uma autentica- ção. Deste modo, o servidor pode facilmente detectar uma busca exaustiva.
Numa modalidade, o cookie que fica armazenado no PC do usuário pode ser ligado ao PC do usuário. Isto pode ser feito não só validando a contra-senha do usuário, mas também a identidade do PC do usuário. Isto pode ser implementado modificando a contra-senha usada para codificar a chave de autenticação armazenada no cookie combinando a contra-senha com o valor de um ou mais elementos de dados que representem a identidade do PC do usuário. Estes elementos de dados podem ser selecionados tais como o número de série do processador do PC do usuário, da placa mãe, do drive do disco rígido, do cartão de ethernet etc. Por exemplo, a chave de autenticação é codificada sob uma combinação (concatenação) da contra-senha do usuário com o número de série (ou uma parte do mesmo) do processa- dor do PC do usuário.
Numa modalidade, a chave de autenticação que é baixa- da para o PC de um novo usuário, quando o usuário migrar de um PC para outro, tem o mesmo valor que a chave de autenticação no PC antigo do usuário. Isto significa que realmente o novo PC do usuário recebeu uma cópia do cookie no PC antigo do usuário.
Em princípio, o usuário pode trabalhar a partir de ambos os PCs antigo e novo. Na prática, isto poderia criar um problema de sincronização, se a variável de entrada for baseada num contador, visto que os contadores em ambos os PCs do usuário podem bem evoluir independentemente. Este problema pode ser evitado, se a variável de entrada para o algoritmo de autenticação não for baseada num conta- dor, mas, ao contrário, for baseada em desafio.
A desvantagem desta modalidade é que uma cópia válida da chave de autenticação permanece presente em cada PC em que o usuário já trabalhou. Isto poderia representar um risco de segurança.
Noutra modalidade da invenção, o servidor gera um novo valor para a chave de autenticação que é baixada para um novo PC de usuário, quando um usuário migrar de um PC de usuário para outro. A operação do servidor também invalida o valor antigo da chave de auten- ticação que é armazenada no cookie do PC antigo do usuário. Isto evita a situação que surge a partir de cópias válidas da chave de autenticação secreta codificada que permanece em PCs antigos do usuário. Uma desvantagem surge se o usuário migrar para outro PC de usuário e então, depois quiser trabalhar no PC original novamente. Nesse caso, o usuário tem de migrar para o PC de usuário mais antigo novamente. Todavia, não é evidente para um applet, que um cookie no PC de usuá- rio foi invalidado. Nesta situação, se o applet num PC de usuário antigo não estiver ciente de que a chave de autenticação disponível para ele foi invalidada, a situação poderia levar a tentativas inválidas seqüenciais, que, por sua vez, poderiam levar a que o servidor bloqueasse a conta do usuário.
Deste modo, num aspecto, a invenção proporciona um método de autenticar um usuário com respeito a um servidor da Web no contexto de uma sessão de navegação na web, operando o usuário um computador pessoal conectado à internet e comunicando com o referido servidor de web por meio de um navegador de Web capaz de administrar e armazenar cookies, método esse que proporciona maior segurança do que o uso de contra-senhas facilmente memorizadas sem exigir que o usuário manter um objetivo físico, compreendendo:
armazenar um cookie no dispositivo de computa- ção pessoal, incluindo o cookie uma primeira chave, estando a primeira chave armazenada no cookie de uma forma codificada, codificada sob uma contra-senha dependente de informações conhecidas apenas do usuário, sendo a primeira chave também conhecida do servidor da Web e associada no servidor da Web ao usuário,
recebendo o navegador a partir do servidor da Web uma página da Web contendo um applet embutido em resposta a um pedido de acesso dirigido para a página da Web, sendo o applet embutido na página da Web exigindo que o usuário introduza a contra- senha,
decifrando o applet a chave codificada armazena- da no cookie, usando a contra-senha, para gerar a referida primeira chave e
empregar a primeira chave para autenticar o usuário para o servidor e/ou assinar dados transmitidos para o servi- dor.
Noutro aspecto, a invenção proporciona um método implementado em servidor que proporciona a autenticação de um usuário para um servidor da Web no contexto de uma sessão de nave- gação na Web que opera com um computador pessoal conectado à internet e que comunica com o citado servidor da Web por meio de um navegador de Web capaz de administrar e armazenar cookies, método esse que proporciona maior segurança do que o uso de contra-senhas facilmente memorizadas, sem exigir que o usuário mantenha um objeti- vo físico compreendendo:
manter um arquivo que associa cada um de uma pluralidade de usuários a uma diferente primeira chave,
em resposta a um acesso por um usuário particu- lar que usa um computador pessoal, transmitir, para o computador pessoal, um applet embutido numa página da Web solicitada pelo acesso do computador pessoal do usuário,
em que o dito applet, quando executado no com- putador pessoal:
requer ao usuário que introduza uma contra-senha,
acessa um cookie, se presente, no compu- tador pessoal do usuário e decifre uma primeira chave codificada armazenada no referido cookie com a contra-senha para recuperar a primeira chave relacionada ao usuário e
usa a primeira chave para autenticar o usuário para o servidor e/ou assine dados transmitidos para o servidor.
A invenção proporciona ainda um método conforme descrito em que o usuário pode acessar o servidor da Web com um computador pessoal particular que já mantém um cookie em armaze- namento incluindo uma primeira chave codificada sob referida contra- senha ou em que o usuário pode acessar o servidor da Web com outro computador pessoal que ainda não mantém o cookie em armazenamen- to ou em que o usuário pode acessar o servidor da web com um compu- tador pessoal particular que já mantém um cookie em armazenamento incluindo uma primeira chave codificada sob a citada contra-senha, mas por meio do que aquele cookie de alguma maneira é perdido ou corrompido,
dito arquivo mantido pelo servidor também inclui um segredo de migração ou um hash de um segredo de migração,
autenticando o referido servidor o usuário, após a recepção de informações que se comparam favoravelmente com o segredo de migração ou o hash do segredo de migração armazenado no servidor ou por meio de um protocolo de autenticação que demonstra que o usuário sabe o valor correto do segredo de migração,
transmitindo o servidor, depois disso, uma indica- ção que significa que o usuário deve ser autenticado quando da apre- sentação da contra-senha.
Breve Descrição dos Desenhos
O método e o equipamento serão descritos com detalhe adicional para possibilitar que as pessoas qualificadas na técnica façam e usem os mesmos, quando correlacionam com os desenhos anexos em que:
a Figura 1 é uma vista esquemática que ilustra a relação entre os elementos principais do DigiPass para a Web incluindo o dispositivo de computação pessoal do usuário (PC) e a sua conexão com o servidor pela internet;
a Figura 2 é um diagrama de blocos mostrando um pedido de acesso do servidor pelo PC;
a Figura 3 ilustra as funções principais do applet de autenticação nas operações de registro e ativação; a Figura 4 ilustra as funções de servidor realiza- das em resposta a informações transmitidas pelo applet nas fases de registro e ativação;
a Figura 5 ilustra as funções principais realizadas tanto pelo servidor e pelo PC na conclusão da fase de ativação;
a Figura 6 ilustra a fase operacional que mostra as funções principais na interação entre o PC e o servidor;
a Figura 7 ilustra a operação de migração que mostra as funções principais na interação entre o novo PC do usuário e o servidor.
Descrição Detalhada
de Modalidades Preferidas
O DigiPass para a Web inclui cinco fases:
a - Pré-registro (opcional): o usuário e o servidor estabelecem algum segredo histórico compartilhado;
b - Fase de registro: o usuário registra-se no servidor empregando um PC.
c - Fase de ativação: o PC do usuário é ativado obtendo um segredo de autenticação compartilhada.
d - Fase operacional: usando o segredo de auten- ticação compartilhada, o PC do usuário pode gerar contra-senhas dinâmicas e/ou assinaturas dinâmicas para autenticar o usuário e as transações originadas pelo usuário;
e - Fase de migração: o usuário migra para um PC diferente. Fase de Pré-Registro
Nesta fase, o usuário e o servidor estabelecem de alguma maneira um segredo histórico compartilhado que será usado na fase seguinte, quando o DigiPass para PC da Web (cliente) será ativado.
Esta fase é opcional no DigiPass para a Web. Está tipicamente incluído, se for exigido um nível de segurança mais elevado. O segredo histórico compartilhado poderia ser:
a - Uma contra-senha de Internet existente que o servidor e o usuário já compartilham ou
b - Uma contra-senha que é especificamente gerada com a finalidade de ser usada numa fase de registro e ativação;
c-O segredo histórico pode ser permutado entre o usuário e o servidor de vários modos. Por exemplo, a permuta pode acontecer:
1 - Numa filial de banco, quando o usuário assinar um contrato para serviço de Internet banking·,
2 - Por um Banco 24 Horas depois que o usuário introduziu o seu cartão Banco 24 Horas e introduziu o código de PIN (identificação pessoal) ou
3 - Como parte de outras informações incluídas numa declaração bancária confidencial impressa enviada para o usuário via correio convencional ou
4 - Na forma de um correio PIN enviado para o usuário via correio registrado.
Fase de Registro Durante esta fase, o usuário registra-se no DigiPass para serviço da Web e o DigiPass para a Web é ativado no PC do usuário (cliente). A Figura 1 ilustra os componentes principais neste processo. Em particular, o usuário opera um dispositivo de computador pessoal 10. Isto é tipicamente um computador pessoal, embora, como mencio- nado, possam também ser usados outros dispositivos. O dispositivo de computação pessoal 10 é conectado (por uma conexão com fios ou sem fios) via Internet 20 a um servidor 30. Uma sessão da Web 40 resulta em que é efetuado o registro do PC 10 do usuário.
A Figura 2 ilustra em diagrama de blocos mostrando componentes importantes do computador pessoal 10, o servidor 30 e identifica as informações importantes que são permutadas durante a parte da sessão da Web 40 em que é implementado o registro.
A Figura 1 ilustra a interação típica entre um usuário, operando um dispositivo de computação pessoal, como o PC 10 e um servidor de Internet 30, em que ambos o PC e o servidor tomam parte numa sessão da Web 40 suportada pela Internet 20. A Figura 1 é representativa de operações nas fases de registro, ativação e operacional do DigiPass para a Web. Uma das vantagens do DigiPass para a Web é a capacidade do usuário de migrar a partir do uso de um PC 10 (mos- trado na Figura 1) para um PC ou outro dispositivo de usuário diferen- te. maneira por que a migração é implementada será descrita em seguida com relação à Figura 7.
Fase de Registro
Antes do uso do DigiPass para a Web, devem ser permu- tados certos dados pelo usuário e pelo servidor. Isto é realizado duran- te a fase de registro. Neste momento, o usuário registra-se no DigiPass para serviço da Web.
A Figura 2 é um diagrama de blocos que mostra a intera- ção entre o PC de usuário 10 e o servidor 30. Antes do registro e/ou da ativação, o PC do usuário 10 não incluiria o applet 12 mostrado na Figura 2. De fato, durante a fase de registro e ativação, o applet 12 é fornecido para o PC de usuário 10 a partir do servidor 30. Além disso, o cookie 14 será criado pelo applet 12, também numa fase mais tardia do processo. Na iniciação da fase de registro, o PC do usuário 10 inclui um navegador 11 que, respondendo a um pedido do usuário, pode transmitir um pedido de acesso 41 para o servidor 30. Dependendo da URL particular contida no pedido de acesso 41, o servidor responde com uma página da Web que contém o applet 12, como ilustrado na Figura 2. O applet 12 inclui conteúdo específico para as funções de registro. O applet 12 pode também incluir conteúdo relacionado com a ativação, embora isto não seja essencial, o conteúdo de applet para a ativação pode ser fornecido mais tarde, especificamente quando for exigida a funcionalidade de ativação. O applet 12 pode também incluir conteúdo específico para funções de autenticação a serem executadas numa fase operacional. Dependendo de como a implementação é estruturada, pode haver apenas um applet único que proporciona o registro, a ativação e a operação. Alternativamente, pode haver applets diferentes para registro, por um lado, e outro applet para a fase de ativação e operacional. Além disso, dependendo do detalhe da implementação mesmo o applet operacional pode ser dividido em diferentes segmentos. Aquelas pessoas qualificadas na técnica entenderão como segmentar o applet de forma que a operação global seja relativamente sem desconti- nuidade.
O navegador carrega o applet 12 e, então, executa-o. A Figura 2 também representa as fases iniciais da fase de registro, porém, no começo da fase de registro, o cookie 14 não estará presente. Em particular, o usuário dirige o navegador 11 para o sítio da Web do servidor 30. Em resposta ao pedido de acesso 41, o servidor 30 trans- mite o applet apropriado, por exemplo, o applet de registro e ativação. Quando o applet 12 é recebido e carregado pelo navegador 11, ele é executado.
As funções principais realizadas pelo applet de ativação são mostradas na Figura 3. A função inicial 301, para estabelecer uma Activation Session Key (Chave de Sessão de Ativação) é opcional. A fim de estabelecer a chave da sessão de ativação, deve haver algum segredo histórico que, antes da execução da função 301, seja compartilhado entre o usuário e o servidor 30. Se este for o caso, então, o usuário pode iniciar a função 301. A função 301 pede ao usuário que entre no segredo histórico. Após a recepção do segredo, o applet 12 usa o segre- do com um protocolo para estabelecer uma chave de sessão comum (a chave da sessão de ativação) na base do segredo histórico compartilha- do. Normalmente, isto é, na maioria dos protocolos, alguns dados (por exemplo, assim chamados 'salts' ou 'nonces') serão gerados e permuta- dos que são usados para derivar a chave de sessão comum do segredo histórico compartilhado; aqueles dados serão chamados de dados de derivação da chave da sessão de ativação. A função 301 conclui com o applet 12 salvando os dados de derivação de chave da sessão de ativa- ção.
Depois disso, função 302, o applet 12 pede ao usuário que escolha e introduza uma userid (UID). Depois disso, a função 303 pede ao usuário que selecione uma pergunta de uma lista de perguntas pré-definidas ("Qual é o nome de solteira de sua mãe?", "Qual é seu filme favorito?", "Qual é o nome de seu animal de estimação?" etc.) e introduz a resposta de segredo àquela pergunta. A resposta será usada na fase de migração e será referida como resposta de segredo de migra- ção ou de segredo.
Depois disso, a função 304 pede ao usuário que escolha, introduza e confirme uma contra-senha local Digipass para a Web. Esta contra-senha Digipass para a Web tornar-se-á a contra-senha usada pelo PC 10 para propósitos de decodificação (ver funções 603, 606 e 607 da Figura 6). Em particular, a contra-senha será usada para proteger uma chave de autenticação que ficará armazenada num cookie no PC. Embora, em algumas modalidades, a contra-senha possa ser transmitida para o servidor, não ficará armazenada no servidor e, em conseqüência, a contra-senha pode ser referenciada como informação que está disponível apenas para o PC 10.
Depois disso, a função 305 deriva a chave de máscara do código de ativação. Isto é realizado numa seqüência de etapas. Primei- ro, o applet gera um Sal Aleatório. Depois disso, o applet 12 lê o valor de algum(ns) elemento(s) de dados que representam a identidade do PC do usuário. Isto pode ser o número de série do processador de PC, o drive do disco rígido, a placa mãe etc. O applet, então, combina o Sal Aleatório, o(s) valor(es) de identificação do PC e a contra-senha local, a fim de obter o chave de máscara do código de ativação usando um algoritmo criptográfico. O algoritmo deve ser selecionado de forma a ter as características seguintes:
1 - Ser muito difícil de apurar uma combinação de Sal Aleatório, valores de identificação de PC e contra-senha local que resultarão num valor dado para uma Chave de Máscara do Código de Ativação e
2 - Para dados valores de de Sal Aleatório e identi- ficação de PC, ser difícil de achar uma contra-senha local que resulte num valor dado para a Chave de Máscara do Código de Ativação.
Um exemplo de um algoritmo criptográfico apropriado é o hashing por SHA-1 da concatenação de Sal Aleatório, valores de identi- ficação de PC e a contra-senha local.
Depois disso, a função 306 grava um cookie de registro no PC do usuário 10. O cookie contém dois ou três elementos. O primeiro elemento são os dados de derivação da Chave de Sessão de Ativação, se a etapa opcional 301 foi realizada, por exemplo, se o usuá- rio e o servidor tiveram, antes da ativação, compartilhado um segredo histórico. O cookie também contém o Sal Aleatório, assim como tam- bém o UID.
Finalmente, na Função 307, o applet 12 transmite uma Mensagem de Registro, contendo quatro elementos, para o servidor. A mensagem contém:
a - UID;
b - o endereço de correio eletrônico do usuário;
c - o hash da resposta de segredo (segredo de migração);
d - a Chave de Máscara de Ativação.
Se a Função opcional 301 foi realizada e corresponden- temente foi estabelecida uma chave de sessão de ativação, a mensagem de registro é codificada com uma Chave de Sessão de Ativação. Isso termina a operação do applet 12 na fase de registro.
A Figura 4 ilustra a resposta do servidor 30 para infor- mações proporcionadas pelo applet 12 na parte final da fase de registro, assim como também nos estágios iniciais da fase de ativação.
Como mostrado na Figura 4, na função inicial, 401, o servidor 30 recebe a mensagem de registro. Na função 402, aquela mensagem é decifrada, se tivesse sido codificada.
Na função 403 o servidor registra o usuário usando a UID, o endereço de correio eletrônico e o hash da resposta de segredo (segredo de migração). Na função 404, o servidor gera um Blob de DigiPass. A instância de Blob de DigiPass para este usuário particular contém a chave de autenticação do segredo de Digipass (originado no servidor) e os parâmetros de algoritmo de Digipass, por exemplo, parâmetros que indicam o tipo de entrada variável para o Digipass OTP (a ser descrito) e o algoritmo de Assinatura, o tipo de formatação para se aplicar a entra- da de variável, o tipo de formatação para se aplicar ao criptograma. A instância de Blob de DigiPass é atribuída à UID para este usuário particular, função 405, isto é, é indexada de forma que o seu conteúdo será associado a este usuário.
O servidor 30, então, realiza as funções 406 até 408.
Em particular, na função 406, o servidor 30 codifica o Blob de DigiPass com a Chave de Máscara do Código de Ativação; o resultado é referido como o Código de Ativação. O servidor 30, então, codifica o Código de Ativação com a Chave de Sessão de Ativação, se disponível. Relembrar que a Chave de Sessão de Ativação é opcional e exige o compartilhamento preparatório de um segredo histórico entre o usuário e o servidor 30. Finalmente, na função 408, o servidor envia um correio eletrônico para o usuário, no endereço de correio eletrônico registrado do usuário, contendo o correio eletrônico uma URL de ativa- ção. A ativação da URL, quando acessada pelo usuário, fornece ao usuário um applet de ativação, conforme descrito em seguida.
A Figura 5 ilustra a conclusão do processo de ativação subseqüente à execução para a função 408 no servidor 30.
Como mostrado na Figura 5, a próxima etapa que é realizada é a função 501 executada pelo PC do usuário 10. A função 501 acontece quando o usuário selecionar a URL de ativação. Quando o servidor 30 receber o acesso a partir do usuário do PC 10, o servidor envia as página da Web que contém o código de ativação específico de DigiPass identificado com o usuário em conjunto com o applet de ativação.
O applet de ativação e o código de ativação de DigiPass é recebido no PC do usuário 10. Na função 503, o applet lê o cookie de registro armazenado no PC 10 (armazenado na função 306).
Na Função 504, o applet solicita ao usuário que entre no segredo histórico, se tiver existido um segredo histórico compartilhado preparatório para a fase de registro. Se tiver existido esse segredo, a Chave de Sessão de Ativação é reconstruída pelo PC 10 (a partir do segredo histórico compartilhado introduzido pelo usuário e os dados de derivação da chave da sessão de ativação armazenados no cookie de registro). O acesso à Chave de Sessão de Ativação permite que o applet decifre o Código de Ativação. Por outro lado, se não existiu nenhum segredo histórico, o Código de Ativação não teria sido codificado e, conseqüentemente, nenhuma operação de decodiílcação seria necessá- ria.
Depois disso, na função 505, o PC de usuário 10 grava o cookie de Blob de DigiPass no PC 10. O cookie de Blob contém a UID, o Sal Aleatório, o Código de Ativação de DigiPass e um valor de contador particular. Para confirmar a ativação bem sucedida, o applet de auten- ticação de DigiPass gera uma contra-senha dinâmica, função 506. O servidor 30 recebe a contra-senha dinâmica, função 507. Isto completa a fase de ativação. A geração da contra-senha dinâmica na função 506 e a sua validação na função 507 confirmam, no servidor, que a ativação foi bem sucedida. Os detalhes da função 506 são os mesmos que as funções 603-609 a serem descritas com relação à Figura. 6.
A Figura 6 ilustra a interação entre o PC 10 e o servidor 30 na fase operacional.
Como mostrado na função 601, a fase operacional é iniciada quando o usuário, subseqüentemente ao registro, dirige o PC 10 para acessar o sítio da Web apropriado dó servidor 30. Em resposta ao acesso pelo usuário, o servidor 30, na função 602, transmite uma página de login para o usuário contendo o applet de autenticação. As funções 603 etc. são dirigidas pelo applet de autenticação no PC 10.
Em particular, na função 603, o usuário é solicitado a entrar na contra-senha local que o usuário escolheu e entrou na função 304 da Figura 3. Na função 604, o applet lê o(s) valor(es) ID do PC (que tinham sido usados no algoritmo de criptografia da função 305). Na função 605, o applet lê o cookie de Blob para obter o Sal Aleatório. Na função 606, o applet reconstrói a Chave de Máscara do Código de Ativação, com base nos dados recuperados nas funções de 603 a 605. Com a chave de máscara do código de ativação recuperada na função 607, o código de ativação é decifrado.
Com base no código de ativação decifrado, a Função 608 gera uma Contra-senha de Uma vez (OTP). A Função 609 envia o OTP para o servidor. A Função 610 (executada pelo servidor 30) proporciona a validação do OTP recebido no servidor 30. O servidor 30 valida o OTP usando os seus próprios valores de dados e gera uma versão de servidor do OTP que é, então, comparado com o OTP recebido. A validação do OTP autentica o usuário para o servidor 30.
Como alternativa para enviar o OTP para o servidor 30 para propósitos de autenticação, o usuário poderia usar o OTP para codificar ou assinar os dados relacionados a transações ou mensagens. Isto iria, com efeito, "assinar" os dados para a transação ou mensagens pelo usuário de forma que os dados e/ou mensagens seriam aceitos pelo servidor 30 como autênticos.
Fase de Migração
O usuário, tendo registrado e usado o DigiPass para serviço da Web a partir de um PC, pode pretender usar o DigiPass para serviço da Web a partir de um PC diferente, um PC que não tenha sido registrado. Além disso, às vezes, é importante que o usuário possa realizar esta função sem qualquer planejamento, por exemplo, numa pressão da base de momento. 0 DigiPass para serviço da Web propor- ciona esta funcionalidade numa fase de migração.
A Figura 7 ilustra a função realizada durante a fase de migração. Inicialmente, o usuário acessa o sítio da Web de servidor 30 (função 701) a partir do PC 100, um computador que não foi registrado e, conseqüentemente, não armazenou os dados que são armazenados no PC 10. O servidor 30 responde ao pedido de acesso do usuário enviando uma página da Web de login com um applet de autenticação, por exemplo, o servidor 30 não responde de modo nenhum diferente- mente ao pedido de acesso a partir do PC 100 que responderia a um pedido a partir de um PC registrado tal como PC 10.
Na função 703, tendo o applet sido instalado no navega- dor 11, determina que não existe nenhum cookie de Blob armazenado, como deveria existir, se o PC tivesse sido ativado e registrado. Em conseqüência, o applet propõe uma função de migração para o usuário, função 703. Para propósitos desta descrição, supomos que o usuário concorda com a função de migração, função 704.
Depois disso, o applet repete as funções de registro e ativação, como descrito com relação às Figuras 3, 4 e 5, com várias modificações. Os endereço de correio eletrônico dos usuários e UID não são mudados. Todavia,, a fim de autenticar o usuário, ao usuário será exigido que introduza a resposta de segredo que previamente tinha sido introduzida na função 303. Além disso, ao usuário será exigido que introduza uma nova contra-senha local, em vez da contra-senha local entrada na função 304. O applet e o servidor empregam a resposta de segredo como um segredo histórico e realizam os processos de registro e de ativação, como já explicado.
Um tema de implementação na fase de migração é se sim ou não a chave de autenticação secreta gerada pelo servidor deve ser a mesma que a chave de autenticação secreta que tinha sido gerada pelo servidor e usada com o PC originalmente registrado 10 ou deve ser uma nova chave de autenticação secreta. Realmente, a chave de autentica- ção secreta gerada na fase de migração pode ser a mesma ou diferente daquelas na medida em que há vantagens e desvantagens a partir de uma ou outra modalidade. Uma vantagem é que usar a mesma chave de autenticação permite ao usuário trabalhar alternadamente a partir do PC antigo e do novo, conforme pretendido. Uma desvantagem é que, se um valor de contador formar um elemento de uma chave, pode haver problemas de sincronização na medida em que o PC antigo e o novo mais do que provavelmente armazenariam diferentes valores de conta- dor. Obviamente, esta desvantagem pode ser eliminada se a variável de entrada para o algoritmo de autenticação não for baseada num conta- dor. Outra desvantagem desta abordagem é que uma cópia válida da chave de autenticação secreta permanece presente em todo PC que o usuário já registrou e ativou. Isto pode bem propriamente representar um risco de segurança.
Alternativamente, o servidor 30 poderia gerar uma nova chave de autenticação secreta para cada novo PC para que o usuário migre. Isto significa necessariamente que a chave de autenticação secreta antiga se torna inválida. A vantagem desta implementação é que a presença de chaves de autenticação secretas em PCs antigos previamente usados não é mais um risco, visto que aquelas chaves são inválidas. Uma desvantagem da abordagem é que, se o usuário, tendo migrado para o PC 100, pretender agora retornar ao PC 10, teria de realizar outra operação de migração, visto que a chave de autenticação secreta contida no PC 10 teria sido invalidada pela migração para o PC 100.
Deve ficar evidente que este Relatório Descritivo descreve um ou mais exemplos de implementações da invenção. Aqueles qualifi- cados na técnica reconhecerão que muitas e variadas mudanças podem ser feitas que caem dentro do espírito e âmbito da invenção. Em conse- qüência, o âmbito das Reivindicações não deve ser limitado pelos exemplos específicos aqui descritos.
Claims (15)
1. Método de Autenticação de Usuário, com respeito a um servidor da Web, no contexto de uma sessão de navegação na Web, operando o usuário um computador pessoal conectado à Internet e comunicando com o referido servidor da Web por meio de um navegador de Web capaz de administrar e armazenar cookies, cujo método proporciona maior segurança do que o uso de contra-senhas facilmente memorizadas sem exigir que o usuário mantenha um objeto físico, caracterizado por que compreende: armazenar um cookie no computador pessoal, incluindo o cookie uma primeira chave, sendo a primeira chave armazenada no cookie de uma forma codificada, codificada sob uma contra-senha dependente de informações conhecidas apenas do usuário, sendo a primeira chave também conhecida do servidor da Web e associada no servidor da Web com o usuário, recebendo o navegador a partir do servidor da Web uma página da Web que contém um applet embutido em resposta a um pedido de acesso dirigido para a página da Web, exigindo o applet embutido na página da Web que o usuário introduza a contra-senha, decifrando o applet a chave codificada armazenada no cookie, usando a contra-senha, para gerar a referida primeira chave e empregando a primeira chave para autenticar o usuário para o servidor e/ou assinar dados transmitidos para o servidor.
2. Método de Autenticação de Usuário, de acordo com a Reivindica- ção 1, caracterizado por que a primeira chave codificada que é arma- zenada no cookie é codificada com uma combinação de uma contra- senha conhecida do usuário e informações que representam pelo menos uma característica do dispositivo de computação pessoal.
3. Método Implementado por Servidor, que fornece a autenticação de um usuário para um servidor da Web no contexto de uma sessão de navegação na Web, que opera com um computador pessoal conectado à Internet e que se comunica com referido servidor da Web por meio de um navegador da Web capaz de administrar e armazenar cookies, cujo método proporciona maior segurança do que o uso de contra-senhas facilmente memorizadas sem exigir que o usuário mantenha um objeto físico, caracterizado por que compreende: manter um arquivo que associa cada um de uma plurali- dade de usuários a uma primeira chave diferente, em resposta a um acesso por um usuário particular que usa um computador pessoal, transmitir, para o computador pessoal, um applet embutido numa página da Web solicitada pelo acesso do computador pessoal do usuário, em que o citado applet, quando executado no computa- dor pessoal: solicita ao usuário que introduza uma contra-senha, acessa um cookie, se presente, no compu- tador pessoal do usuário e decifra uma primeira chave codificada armazenada no referido cookie com a contra-senha para recuperar a primeira chave relacionada ao usuário e usa a primeira chave para autenticar o usuário para o servidor e/ou assinar dados transmitidos para o servi- dor.
4. Método Implementado por Servidor, de acordo com a Reivindica- ção 3, caracterizado por que o usuário pode acessar o servidor da Web com um computador pessoal particular que já mantém um cookie em armazenamento, incluindo uma primeira chave codificada sob a citada contra-senha ou em que o usuário pode acessar o servidor da Web com outro computador pessoal que ainda não mantém o cookie em armaze- namento ou em que o usuário pode acessar o servidor da Web com um computador pessoal particular que já mantém um cookie em armaze- namento incluindo uma primeira chave codificada sob dita contra- senha mas em que aquele cookie de alguma maneira é perdido ou corrompido, caracterizado por que o referido arquivo mantido pelo servidor também inclui um segredo de migração ou um hash de um segredo de migração, autentica o citado servidor o usuário após a recepção de informações que compara favoravelmente ao segredo de migração ou o hash do segredo de migração armazenado no servidor ou por meio de um protocolo de autenticação que demonstra que o usuário sabe o valor correto do segredo de migração, transmite, depois disso, o servidor uma indicação que significa que o usuário deve ser autenticado pela apresentação da contra-senha.
5. Método Implementado por Servidor, de acordo com a Reivindica- ção 4, caracterizado por que as informações incluem a primeira chave codificada sob a contra-senha.
6. Método Implementado por Servidor, de acordo com a Reivindica- ção 4, caracterizado por que as informações contêm uma segunda chave, diferente da primeira chave, codificada sob a contra-senha, em que a segunda chave pode ser usada em vez da primeira chave pelo applet para autenticar o usuário para o servidor.
7. Método Implementado por Servidor, de acordo com a Reivindica- ção 4, caracterizado por que o applet transmitido para o computador pessoal é transmitido em um ou mais segmentos.
8. Método Implementado por Servidor, de acordo com a Reivindica- ção 7, caracterizado por que um segmento particular do applet é apenas transmitido a pedido.
9. Sistema de Autenticação de Usuário, com respeito a um servidor da Web no contexto de uma sessão de navegação na Web, operando o usuário um computador pessoal conectado à Internet e que se comuni- ca com o referido servidor da Web por meio de um navegador de Web capaz de administrar e armazenar cookies, cujo sistema proporciona segurança maior do que o uso de contra-senhas facilmente memoriza- das sem exigir que o usuário mantenha um objeto físico, caracterizado por que compreende: uma memória para armazenar um cookie no computador pessoal, incluindo o cookie uma primeira chave, sendo a primeira chave armazenada no cookie numa forma codificada, sendo codificada sob uma contra-senha dependente de informações conhecidas apenas do usuário, sendo a primeira chave também conhecida do servidor da Web e associada no servidor da Web ao usuário, um navegador que recebe do servidor da Web uma página da Web contendo um applet embutido em resposta a um pedido de acesso dirigido para a página da Web, exigindo o applet embutido na página da Web que o usuário introduza a contra-senha, decifrando o applet a chave codificada armazenada no cookie, usando a contra-senha, para gerar a citada primeira chave e empregando o applet ainda a primeira chave para auten- ticar o usuário para o servidor e/ou assinando dados transmitidos para o servidor.
10. Sistema de Autenticação de Usuário, de acordo com a Reivindi- cação 10, caracterizado por que a primeira chave codificada que é armazenada no cookie é codificada com uma combinação de uma contra-senha conhecida do usuário e informações que representam pelo menos uma característica do dispositivo de computação pessoal.
11. Sistema de Autenticação de Usuário, para um servidor da Web, no contexto de uma sessão de navegação na Web, com um computador pessoal conectado à internet e que se comunica com o referido servidor da Web por meio de um navegador da Web capaz de administrar e armazenar cookies, que proporciona maior segurança do que o uso de contra-senhas facilmente memorizadas sem exigir que o usuário man- tenha um objeto físico, caracterizado por que compreende: armazenar no servidor um arquivo que associa cada um de uma pluralidade de usuários a uma primeira chave diferente, meios, em resposta a um acesso por um usuário particu- lar que usa um computador pessoal, para transmitir para o computador pessoal um applet embutido numa página da Web solicitada pelo acesso do computador pessoal do usuário, o referido applet, quando executado no computador pessoal; solicita que o usuário introduza uma contra-senha, acessa um cookie, se estiver presente, no computador pessoal do usuário e decifra uma primeira chave codificada armazenada no citado cookie com a contra-senha para recuperar a primeira chave relacionada ao usuário e usa a primeira chave para autenticar o usuário para o servidor e/ou assinar dados transmitidos para o servi- dor.
12. Sistema de Autenticação de Usuário, de acordo com a Reivindi- cação 12, caracterizado por que o usuário pode acessar o servidor da Web com um computador pessoal particular que já mantém um cookie em armazenamento incluindo uma primeira chave codificada sob a referida contra-senha ou em que o usuário pode acessar o servidor da Web com outro computador pessoal que ainda não mantém o cookie em armazenamento ou em que o usuário pode acessar o servidor da Web com um computador pessoal particular que já mantém um cookie em armazenamento incluindo uma primeira chave codificada sob a citada contra-senha mas em que aquele cookie de alguma maneira é perdido ou corrompido, incluindo também dito arquivo armazenado no servidor um segredo de migração ou um hash de um segredo de migração, incluindo ainda o referido servidor meios de autenticação do usuário após a recepção de informações que compara favoravelmente com o segredo de migração ou o hash do segredo de migração armaze- nado no servidor ou por meio de um protocolo de autenticação que demonstra que o usuário sabe o valor correto do segredo de migração, transmitindo o servidor uma indicação que significa que o usuário deve ser autenticado na apresentação da contra-senha.
13. Sistema de Autenticação de Usuário, de acordo com a Reivindi- cação 12, caracterizado por que as informações incluem a primeira chave codificada sob a contra-senha.
14. Sistema de Autenticação de Usuário, de acordo com a Reivindi- cação 13, caracterizado por que as informações contêm uma segunda chave, diferente da primeira chave, codificada sob a contra-senha, em que a segunda chave pode ser usada em vez da primeira chave pelo applet para autenticar o usuário para o servidor.
15. Sistema de Autenticação de Usuário, de acordo com a Reivindi- cação 13, caracterizado por que o meio de transmissão do applet transmite o applet em um ou mais segmentos.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/US2006/008439 WO2007102823A1 (en) | 2006-03-09 | 2006-03-09 | Digipass for the web-functional description |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0621455A2 true BRPI0621455A2 (pt) | 2011-12-13 |
Family
ID=38475164
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0621455-0A BRPI0621455A2 (pt) | 2006-03-09 | 2006-03-09 | sistema e métodos de autenticação de usuário e implementado por servidor |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US8261087B2 (pt) |
| EP (1) | EP1997270B1 (pt) |
| CN (1) | CN101427510B (pt) |
| BR (1) | BRPI0621455A2 (pt) |
| DK (1) | DK1997270T3 (pt) |
| ES (1) | ES2530715T3 (pt) |
| MX (1) | MX2008011277A (pt) |
| PL (1) | PL1997270T3 (pt) |
| WO (1) | WO2007102823A1 (pt) |
Families Citing this family (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8559637B2 (en) * | 2008-09-10 | 2013-10-15 | Verizon Patent And Licensing Inc. | Securing information exchanged via a network |
| CN101662465B (zh) * | 2009-08-26 | 2013-03-27 | 深圳市腾讯计算机系统有限公司 | 一种动态口令验证的方法及装置 |
| US8572394B2 (en) * | 2009-09-04 | 2013-10-29 | Computer Associates Think, Inc. | OTP generation using a camouflaged key |
| AU2011245059A1 (en) * | 2010-04-30 | 2012-11-08 | Kl Data Security Pty Ltd | Method and system for enabling computer access |
| SE1050605A1 (sv) * | 2010-06-14 | 2011-12-15 | Technology Nexus Ab | Ett system och förfarande för att utföra autentisering och digital signering med två faktorer |
| US8490165B2 (en) | 2010-06-23 | 2013-07-16 | International Business Machines Corporation | Restoring secure sessions |
| US8572268B2 (en) | 2010-06-23 | 2013-10-29 | International Business Machines Corporation | Managing secure sessions |
| US9444620B1 (en) * | 2010-06-24 | 2016-09-13 | F5 Networks, Inc. | Methods for binding a session identifier to machine-specific identifiers and systems thereof |
| US8832807B1 (en) * | 2010-08-05 | 2014-09-09 | Christine E. Kuo | Method and apparatus for asynchronous dynamic password |
| KR101264299B1 (ko) * | 2011-01-20 | 2013-05-22 | 에스케이플래닛 주식회사 | Ｃｐｎｓ 환경에서 사용자 인증을 위한 인증키 발급 시스템 및 방법 |
| AU2011200413B1 (en) * | 2011-02-01 | 2011-09-15 | Symbiotic Technologies Pty Ltd | Methods and Systems to Detect Attacks on Internet Transactions |
| FR2976437B1 (fr) * | 2011-06-08 | 2014-04-18 | Genmsecure | Procede de securisation d'une action qu'un dispositif actionneur doit accomplir a la demande d'un utilisateur |
| US8918853B2 (en) * | 2011-06-29 | 2014-12-23 | Sharp Laboratories Of America, Inc. | Method and system for automatic recovery from lost security token on embedded device |
| US8789150B2 (en) * | 2011-09-22 | 2014-07-22 | Kinesis Identity Security System Inc. | System and method for user authentication |
| US8667569B2 (en) * | 2011-09-29 | 2014-03-04 | Target Brands, Inc. | Credentials management |
| US10979226B1 (en) * | 2011-10-12 | 2021-04-13 | Cybrsecurity Corporation | Soft-token authentication system with token blocking after entering the wrong PIN |
| US11424930B2 (en) * | 2012-05-22 | 2022-08-23 | Barclays Bank Delaware | Systems and methods for providing account information |
| US8954004B1 (en) | 2012-09-20 | 2015-02-10 | Trend Micro Incorporated | Systems and methods for accessing websites using smartphones |
| US9608983B2 (en) * | 2013-04-30 | 2017-03-28 | Sensormatic Electronics, LLC | Authentication system and method for embedded applets |
| US9305161B1 (en) * | 2013-06-24 | 2016-04-05 | Emc Corporation | Password hardening system using password shares distributed across multiple servers |
| US9325684B2 (en) | 2013-08-02 | 2016-04-26 | Qualcomm Incorporated | Method for authenticating a device connection for a website access without using a website password |
| US10013563B2 (en) * | 2013-09-30 | 2018-07-03 | Dell Products L.P. | Systems and methods for binding a removable cryptoprocessor to an information handling system |
| US9426156B2 (en) * | 2013-11-19 | 2016-08-23 | Care Innovations, Llc | System and method for facilitating federated user provisioning through a cloud-based system |
| US20150213253A1 (en) * | 2014-01-28 | 2015-07-30 | Qualcomm Incorporated | Authorizing an application for use by a computing device |
| US9934393B2 (en) * | 2015-04-21 | 2018-04-03 | Sap Se | Transparent namespace-aware mechanism for encrypted storage of data within web applications |
| US10681078B2 (en) | 2016-06-10 | 2020-06-09 | Sophos Limited | Key throttling to mitigate unauthorized file access |
| US10791097B2 (en) | 2016-04-14 | 2020-09-29 | Sophos Limited | Portable encryption format |
| CN105871927B (zh) * | 2016-06-17 | 2019-09-06 | 北京奇虎科技有限公司 | 微端的自动登录方法及装置 |
| GB2551983B (en) | 2016-06-30 | 2020-03-04 | Sophos Ltd | Perimeter encryption |
| US10320808B2 (en) * | 2016-10-25 | 2019-06-11 | Cerner Innovation, Inc. | Clickjacking prevention |
| US11063758B1 (en) | 2016-11-01 | 2021-07-13 | F5 Networks, Inc. | Methods for facilitating cipher selection and devices thereof |
| US10218691B2 (en) | 2016-11-30 | 2019-02-26 | Airwatch Llc | Single sign-on framework for browser-based applications and native applications |
| US10320771B2 (en) | 2016-11-30 | 2019-06-11 | Airwatch Llc | Single sign-on framework for browser-based applications and native applications |
| CN109302446B (zh) * | 2018-08-15 | 2022-10-25 | 广州市保伦电子有限公司 | 跨平台访问方法、装置、电子设备及存储介质 |
| US11042629B2 (en) * | 2018-10-09 | 2021-06-22 | EMC IP Holding Company LLC | Preventing malicious lockout of user accounts |
| CN110048850A (zh) * | 2019-03-26 | 2019-07-23 | 重庆邮电大学 | 一种基于改进ssl/tls协议的车联网数据安全传输技术 |
| CN111176752B (zh) * | 2019-12-20 | 2023-05-16 | 汪佐怀 | 一种浏览器页面内嵌窗口小程序的方法及装置 |
| US11880449B2 (en) * | 2020-02-20 | 2024-01-23 | Lenovo (Singapore) Pte. Ltd. | Temporary password for password reset |
| US11502840B2 (en) * | 2020-10-08 | 2022-11-15 | Authentico Technologies Ab | Password management system and method |
| CN112328986A (zh) * | 2020-11-26 | 2021-02-05 | 西安四叶草信息技术有限公司 | 一种用户身份验证方法、装置、服务器及存储介质 |
| US11929992B2 (en) * | 2021-03-31 | 2024-03-12 | Sophos Limited | Encrypted cache protection |
| US11831688B2 (en) * | 2021-06-18 | 2023-11-28 | Capital One Services, Llc | Systems and methods for network security |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8019881B2 (en) * | 1998-11-30 | 2011-09-13 | George Mason Intellectual Properties, Inc. | Secure cookies |
| US6985953B1 (en) * | 1998-11-30 | 2006-01-10 | George Mason University | System and apparatus for storage and transfer of secure data on web |
| US6920560B2 (en) * | 1999-12-30 | 2005-07-19 | Clyde Riley Wallace, Jr. | Secure network user states |
| US7082532B1 (en) * | 1999-12-30 | 2006-07-25 | Intel Corporation | Method and system for providing distributed web server authentication |
| US6954799B2 (en) * | 2000-02-01 | 2005-10-11 | Charles Schwab & Co., Inc. | Method and apparatus for integrating distributed shared services system |
| US7299364B2 (en) * | 2002-04-09 | 2007-11-20 | The Regents Of The University Of Michigan | Method and system to maintain application data secure and authentication token for use therein |
| US7100049B2 (en) * | 2002-05-10 | 2006-08-29 | Rsa Security Inc. | Method and apparatus for authentication of users and web sites |
| US7359976B2 (en) * | 2002-11-23 | 2008-04-15 | Microsoft Corporation | Method and system for improved internet security via HTTP-only cookies |
| US7237118B2 (en) * | 2002-12-05 | 2007-06-26 | Microsoft Corporation | Methods and systems for authentication of a user for sub-locations of a network location |
| US20050010764A1 (en) * | 2003-06-26 | 2005-01-13 | International Business Machines Corporation | System and method for securely transmitting, and improving the transmission of, tag based protocol files containing proprietary information |
| US7660904B2 (en) * | 2004-05-11 | 2010-02-09 | Microsoft Corporation | Providing keys to share data within an instant messaging session |
| US7665127B1 (en) * | 2004-06-30 | 2010-02-16 | Jp Morgan Chase Bank | System and method for providing access to protected services |
| US7475152B2 (en) * | 2004-09-20 | 2009-01-06 | International Business Machines Corporation | Approach to provide self-protection function to web content at client side |
| US8275664B2 (en) * | 2004-10-26 | 2012-09-25 | The Coca-Cola Company | Transaction system and method |
-
2006
- 2006-03-09 ES ES06737600T patent/ES2530715T3/es active Active
- 2006-03-09 BR BRPI0621455-0A patent/BRPI0621455A2/pt not_active Application Discontinuation
- 2006-03-09 EP EP06737600.4A patent/EP1997270B1/en active Active
- 2006-03-09 CN CN2006800537570A patent/CN101427510B/zh not_active Expired - Fee Related
- 2006-03-09 DK DK06737600.4T patent/DK1997270T3/en active
- 2006-03-09 PL PL06737600T patent/PL1997270T3/pl unknown
- 2006-03-09 US US12/282,269 patent/US8261087B2/en active Active
- 2006-03-09 MX MX2008011277A patent/MX2008011277A/es active IP Right Grant
- 2006-03-09 WO PCT/US2006/008439 patent/WO2007102823A1/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| PL1997270T3 (pl) | 2015-05-29 |
| DK1997270T3 (en) | 2015-02-16 |
| ES2530715T3 (es) | 2015-03-04 |
| MX2008011277A (es) | 2008-11-25 |
| US20110314290A1 (en) | 2011-12-22 |
| EP1997270A4 (en) | 2013-08-21 |
| EP1997270A1 (en) | 2008-12-03 |
| EP1997270B1 (en) | 2014-12-03 |
| CN101427510A (zh) | 2009-05-06 |
| WO2007102823A1 (en) | 2007-09-13 |
| CN101427510B (zh) | 2011-05-11 |
| US8261087B2 (en) | 2012-09-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0621455A2 (pt) | sistema e métodos de autenticação de usuário e implementado por servidor | |
| TWI543574B (zh) | 使用瀏覽器認證線上交易的方法 | |
| US9787689B2 (en) | Network authentication of multiple profile accesses from a single remote device | |
| US20100017596A1 (en) | System and method for managing authentication cookie encryption keys | |
| US20090037725A1 (en) | Client-server opaque token passing apparatus and method | |
| BRPI0915875B1 (pt) | método para uso com pelo menos um dispositivo portátil e aparelho | |
| US8601264B2 (en) | Systems and methods of user authentication | |
| US20160204933A1 (en) | Personal information management system, method and service | |
| BRPI0707397A2 (pt) | método para melhorar a capacidade de restrição em usar um aplicativo de software | |
| US9954853B2 (en) | Network security | |
| US11997210B2 (en) | Protection of online applications and webpages using a blockchain | |
| Das | A secure and robust password-based remote user authentication scheme using smart cards for the integrated epr information system | |
| US20230108034A1 (en) | Method and System for Secure Interoperability between Medical Devices | |
| CN114244508A (zh) | 数据加密方法、装置、设备及存储介质 | |
| Diomedous et al. | Practical password hardening based on TLS | |
| CN115378740B (zh) | 一种基于可信openssh双向认证登录的实现方法 | |
| CN111404946B (zh) | 基于浏览器的账户认证方法及服务器 | |
| EP2530618B1 (en) | Sign-On system with distributed access | |
| KR20190017370A (ko) | 해시체인 기반의 일회용 패스워드를 이용한 사용자 인증 방법 및 장치 | |
| Corella et al. | An example of a derived credentials architecture | |
| Hernández Plaza | State-of-the art teaching material of the OWASP Top 10 | |
| WO2023126133A1 (en) | Method for managing a remote server | |
| CN116743367A (zh) | 一种消息处理方法及装置、电子设备、存储介质 | |
| Foltz et al. | INSTITUTE FOR DEFENSE ANALYSES | |
| Cheung et al. | Strongly authenticated URLs: Integrating Web browsers and |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B06G | Technical and formal requirements: other requirements [chapter 6.7 patent gazette] |
Free format text: APRESENTE NOVAS VIAS DE RESUMO, SEM REPRESENTACOES GRAFICAS, CONFORME DETERMINA O ITEM 15.3.3.5 DO AN NO 127/1997. |
|
| B06T | Formal requirements before examination [chapter 6.20 patent gazette] | ||
| B15K | Others concerning applications: alteration of classification |
Free format text: AS CLASSIFICACOES ANTERIORES ERAM: H04L 9/32 , H04K 1/00 , H04L 9/00 Ipc: H04L 9/08 (1990.01), H04L 9/32 (1990.01), H04L 29/ |
|
| B11E | Dismissal acc. art. 34 of ipl - requirements for examination incomplete | ||
| B11T | Dismissal: dismissal of application maintained |