BR102014015634A2

BR102014015634A2 - método implementado por computador para evitar ataques contra sistemas de autorização, e produto de programa de computador

Info

Publication number: BR102014015634A2
Application number: BR102014015634A
Authority: BR
Inventors: Antonio Guzmán Sacristán; David Barroso Berrueta; José Maria Alonso Cebrián; José María Palazón Romero
Original assignee: Telefonica Digital España S L U
Priority date: 2013-06-24
Filing date: 2014-06-24
Publication date: 2016-03-29
Also published as: ES2701613T3; BR102014015637A8; EP2819370A1; ES2753243T3; US9832192B2; BR102014015634A8; US10063543B2; BR102014015634B1; EP2819370B1; US20140380453A1; EP2819371A1; US20140380431A1; EP2819371B1; BR102014015637A2

Abstract

método implementado por computador para evitar ataques contra sistemas de autorização e seus produtos de programa de computador. um método implementado por computador e produtos de programa de computador para evitar ataques contra sistemas de autorização. o método implementado por computador compreendendo controle do acesso a diferentes recursos e ações definidos para um usuário por um primeiro servidor, redução do tempo de exposição no qual essas operações estão disponíveis e estabelecimento de uma verificação de canal dupla por meio do uso de um segundo servidor. os programas de computador implementam o método.

Description

MÉTODO IMPLEMENTADO POR COMPUTADOR PARA EVITAR ATAQUES CONTRA SISTEMAS DE AUTORIZAÇÃO, PROGRAMA DE COMPUTADOR, E PRODUTO DE PROGRAMA DE COMPUTADOR

CAMPO DA TÉCNICA [001] A presente invenção é direcionada, em geral, aos sistemas de autenticação e autorização e, mais particularmente, a um método implementado por computador e produtos de programa de computador para evitar ataques contra sistemas de autorização, nos quais o acesso a diferentes recursos e ações, definidos para um usuário, ê controlado.

HISTÓRICO DA INVENÇÃO [002] Nos últimos anos, mercado de detecção de fraude na web aumentou de maneira considerável, assim, a inovação em processos de autenticação e autorização se tornou 13 yx^IXCie XmpOJ-CcàllCXdL * [003] A complexidade crescente de aplicativos levou à adoção de muitas técnicas de segurança altamente sofisticadas. Uma das classificações que pode ser proposta para o estudo dessas técnicas de segurança permite distinguir entre soluções de autenticação e soluções de autorização. As técnicas de autenticação são projetadas para verificar se a pessoa é aquela que alega ser. A fim de adicionar mais confiabilidade na verificação de que, de fato, uma pessoa corresponde à identidade que está sendo verificada, muitos esquemas de autenticação alternativos podem ser considerados ou diversos fatores para construir essa autenticação podem ser estendidos. [004] Há muitas soluções projetadas para potencializar os processos de autenticação e, por extensão, para fortificar os processos de autorização. Uma vez que usuários foram identificados de maneira segura, há esquemas de autorização que permitem flexibilidade e robustez na atribuição de permissões aos usuários para garantir acesso seguro a recursos de sistema. Entretanto, há ameaças que ainda não podem ser impedidas ao adotar qualquer um dos esquemas existentes para a autenticação/autorização, ou essa adoção é muito cara de ser paga. Essas ameaças afetam diretamente a maneira do acesso a recursos específicos a ser realizado. Um método para tratar dessas ameaças envolve o projeto de mecanismos de segurança completamente novos. Esses mecanismos devem garantir que, uma vez que a identidade de um usuário foi verificada e o nível de autorização a um recurso, para esse usuário, foi verificado, as ações tomadas pelo usuário desse recurso não são interceptadas e modificadas por qualquer pessoa que queria atacar. [005] Em qualquer modelo de autorização, H -j ψ pr*pri f*pc! TI T naa CXUF» "Ρ^Γ*τΤΐΙ"ΗΓΠ afPSSO rH VfTfíOS

*v#% Am hUh. XA* 4, A V** K** X* X*** X** A A -A,* Vf v% W W*. V** 4« X** A* Ά*. W· Vi Vi X**1 V* W V-* Mt V** Am V X** -W ***4 V*** hm* A·* Xm« V-* VA. A* XA de sistema são incluídas. As informações de papel de usuário, os dados de controle de acesso providos quando o usuário for autenticado, são exemplos de informações que podem ser utilizadas para determinar a quem dar acesso a quais recursos e como esse acesso tem de ser garantido. Por fim, a determinação do que deve ser acessado pelos usuários será específica para cada aplicativo. Por esse motivo, algumas vezes, será difícil prover um esquema de autorização geral. Será necessário definir uma lógica especifica por aplicativo para determinar quais usuários podem acessar e como eles devem realizar esses acessos. A partir dessa ideia, há muitas soluções que propõem esquemas seguros e flexíveis para a implementação da autorização. Em todas essas soluções, a segurança deve ser garantida pela seleção correta do mecanismo de autenticação e uma implementação correta do esquema de autorização selecionado. [006] Algumas das soluções proveem flexibilidade ao definir o seu próprio SDK para encorajar o uso de seus esquemas para autenticação/autorização. Hoje em dia, a maioria dos SDK tem base nos conceitos introduzidos por OAuth e não supõem um risco por si sõ. Isso se aplica a Microsoft Live Connect, Facebook PHP SDK e Windows 8 SDK Authentication Broker. Se existirem, as ameaças devem vir de um uso deficiente desses SDK. Na verdade, independentemente das ameaças derivadas por uma mã implementação do esquema escolhido, a maioria das ameaças que podem ser definidas em um sistema de autorização coincide com as ameaças definidas ΤΛΆ Ύ'ρι ei ei- PTíia £5 Hp sa λ t t“ ΡΤΊ Rcaa Γ* (Π 1 ΪΊ Γ* Ί Γ*) Αγ*ι p-j a j~ parn Hp -F pa ητ pa-y* VA J»» VA fcw* A. W V*» l V l. VA KJ VA V#» Vi V4 W V*« W A. V* VA Vp VA V-/ · W VA VA VA V/ VA «A> *. J» V-» <*» VA * A W A. Wl W Vrf lll VA V»* J— VA <C*J V»*> JV com o mau uso das credenciais utilizadas para administrar eirrnissoes que gaxanueTTi acesso aos irecuirsos / loj # [007] Em [2] , quatro níveis diferentes são sriniuos em cs.riiios cie coxisequ.en.cxas Qe ex^xros cie auceiiuxcaçao e autorização e mã utilização de credenciais. Nível 1 é o nível mais baixo (o mais inseguro) e o nível 4 ê o mais alto. [008] * Nível 1 - Um atacador pode realizar pesquisas de longon repetidas ao adivinhar valores possíveis do autenticador de token. Um atacador também é capaz e reproduzir mensagens capturadas anteriormente (entre um usuário legítimo e um verificador) para autenticar aquele usuário ao verificador. NIST recomenda o uso de uma autenticação de único ou múltiplos fatores sem comprovação de identidade, a fim de prover proteção contra essa adivinhação online e ataques de repetição. [009] · Nível 2 - Um atacador pode prestar atenção passivamente ao protocolo de autenticação para capturar informações que podem ser utilizadas em um ataque ativo subsequente â dissimulação como o usuário. NIST recomenda o uso de autenticação de único ou múltiplos fatores para prover proteção contra esses ataques de interceptação e todos os ataques do nível 1. [010] · Nível 3-0 atacador se posiciona entre o usuário e o verificador, de modo que possa interceptar e alterar o conteúdo das mensagens de protocolo de autenticação. O atacador tipicamente representa o verificador ao usuário e, simultaneamente, representa o usuário ao verificador. A condução de uma troca ativa com ambas as partes pode permitir simultaneamente que o atacador utilize mensagens de autenticação enviadas por uma parte legítima paira se sxxfcariticaxr com sxic0sso a ontira panrti.0» NXST irôcorriôricia o uso de uma autenticação de múltiplos fatores e uso amplo de DTP TaiDhpin ρπισρτρ um t-olcf^n nH 1 í 7,3dn T*a aiifpnt i narso naτή J. 4» » «U WV VW *1» V*. V»*· A* W> VAM.*. W J VVw· A J. VA W «** A- fcA Vt VA VA IIA* M. Vrt. VA. W1 V· A. A W «V. S«i VA. Vy# VA VA VA A- VA ser destravado pelo usuário utilizando uma senha ou biometria. A adoção dessas soluções provê proteção contra ataques de representação de verificador, ataques MitM e os ataques do nível 2. [011] · Nível 4 - Um atacador é capaz de se inserir entre um usuário e um verificador, subsequente a uma troca de autenticação de sucesso entre as duas últimas partes. O atacador é capaz de se colocar como um usuário ao verificador, ou vice-versa, para controlar a troca de dados de sessão. Por outro lado, o atacador pode comprometer ou, de outra forma, explorar os tokens de autenticação e pode interceptar todas as comunicações de entrada ou saída do dispositivo (ataques diretos no dispositivo (MitD) ou ataques diretos no navegador (MitB)). O atacador pode fazer isso, infectando o sistema com malware. NIST sugere o uso de Autenticação de múltiplos fatores com hardware resistente a violação, certificado por FIPS-14Q-2 (tokens de hardware) [4] para obter proteção contra esses ataques de sequestro de sessão e os ataques do nível 3, [012] Para os primeiros três níveis, ataques e soluções existentes são, ambos, focalizados na maneira de verificação da identidade do usuário. No nível 4, NIST propõe o uso de soluções contra sequestro de sessão e outros ataques aos processos de autenticação. Esses sequestros de sessão envolvem um atacador levar vantagem da troca legítima de credenciais que um usuário faz se sujeitar ao processo de autenticação. Uma vez que essa validação é realizada, o atacador, então, intervém na comunicação que ocorre. Esses tipo de ataque pode ser implementado de duas formas: agindo ativamente, sequestrando a conexão e deixando de fora para o usuário legítimo, ou, deixando oculta e modificando o conteúdo da comunicação de maneira transparente ao usuário. Qualquer que seja a implementação desse ataque, é importante observar que esse é um ataque que visou quebrar o sistema de autorização, deixando intacto, embora sem uso, o sistema autenticação. Embora haja alternativas para proteger de maneira pró-ativa sistemas dessa ameaça, não há solução adequada para diminuir os efeitos do ataque, uma vez que o dispositivo do qual o acesso a recurso é solicitado está comprometido. [013] NIST sugere o emprego de hardware resistente à violação, certificado por FIPS-140-2 (tokens de hardware) [4] . A utilização desses dispositivos provê aos usuários a capacidade de gerar uma senha de único uso (senha de uma vez, OTP) para comprovar sua identidade a cada transação. Além disso, há implementações de hardware desses tokens que podem gerar outras OTPs codificadas para conter informações sobre como completar uma transação específica. [014] Diferentes critérios podem ser definidos para estabelecer uma comparação entre os esquemas de autenticação/autorização. Em [1] , os autores sugerem a necessidade de definir os três critérios, a fim de realizar uma comparação efetiva. Esses aspectos são: segurança, usabilidade e complexidade na implementação (capacidade de implantação). Esse documento apresenta um estudo intenso para instrumentar a comparação por meio da definição de métricas.

UaDcIa a. S0guXx xGSuITle aS mcUllCaS Q.GX XTlXCtciS ptXXta Caud Ο X7 X tü# 0 X" X O [015] No caso do critério de segurança, o conjunto de métrica proposto resume todos os aspectos que são comumente estimados na definição de um modelo de ameaça. Na definição desses modelos, é necessário adotar diversas decisões. E essas decisões definem o cenário de funcionamento. Por exemplo, no caso de OAuth 2.0 [5] , as suposições adotadas são como segue: [016] · O atacador tem acesso completo à rede entre os servidores de cliente e de autorização e o cliente e o servidor de recurso, respectivamente. O atacador pode violar quaisquer comunicações entre essas partes. Não se presume que tenha acesso à comunicação entre o servidor de autorização e o servidor de recurso. [017] · Um atacador tem recursos ilimitados para organizar um ataque. [018] · Duas das três partes envolvidas no protocolo OAuth podem conspirar para montar um ataque contra a terceira parte. Por exemplo, o cliente e servidor de autorização podem estar sob o controle de um atacador e conspirarem para enganar um usuário para ganhar acesso aos recursos. [019] Observando as métricas introduzidas acima, é possível determinar quais soluções, correspondentes ao maior nível de segurança (nível 4), têm desempenho ruim na capacidade de implantação e usabílidade. Uma vez que a avaliação de um sistema permite determina em qual nível seu 1 & L. GlTlci O.S ci clU* ©X3,· w·· jl O cá, Cy* cá. O w Clw £» S ΧΓ XIllJ-P J». SXJL w SCXO / € Χ1Θ O €2 S S ci X. X O avaliar se os usuários são autenticados de maneira segura e correta. Embora haja algumas ferramentas que ajudam nessa tarefa [3] , [€] , implantações no nível 4 são difíceis de avaliar corretamente. Em termos de usabílidade, o uso de tokens de hardware resistentes à violação vai contra a adição dessas soluções pelos usuários, e se comprovou que essa situação leva a uma mã utilização dos sistemas de credencial. Esses tokens são caros. Eles são dispositivos independentes que o usuário tem de deter e que podem ser empregados somente com um provedor de serviço. Se os usuários tiverem de lidar com mais de um provedor de serviços que adotou esses tokens de hardware resistentes â violação, eles têm de deter tantos tokens quantos provedores de serviços tiverem. [020] Além disso, em termos de autorização, em [7] , os autores explicam que, além de algumas questões de segurança de cada SDK, os desenvolvedores que escolherem integrar um deles fazem suposições que podem levar a problemas de segurança. Isso se deve aos SDKs geralmente não serem bem documentados e as falhas de segurança quase sempre resultam de atacadores que encontram maneiras de violar essas suposições com as quais os implementadores de sistema contam. [021] Junto a essas dificuldades, outros problemas devem ser considerados para entender o aumento constante em fraude que se origina do furto de identidades digitais. Por exemplo, não ê possivel medir um nível de segurança homogêneo em todas as contas digitais de usuários. Ê necessária uma solução que possa equalizar o nível de segurança de todas as contas digitais que um usuário possui. Essa solução deve estender essa segurança não somente aos processos de autenticação, mas também aos processos de SlltTin' 7ΛΡΏΠ nfp rpriircf) p OR ΉΊΓΟΓ’ΡΓΪ 1 ΗΊΡΠ t" OF3 3 P Ί 0HRCÍ053 νΛ. UA, w Vrf »IU JU Μ n V.A. Ve» «U Vef Vw» V»*. W Vu» W 'W VA V*/ Iw-1 VwA h»» V* vA» »11 V»# AA I»» Vrf» t™* ·*·* W V» «A» V*» Φ A» V,™» W W a essas contas. [022] Portanto, uma abordagem diferente é necessária para aprimorar a segurança geral nos sistemas de autenticação/autorização, qualquer que seja o esquema ou esquemas adotado/s, minimizando o impacto na usabilidade e capacidade de implantação desses sistemas. REFERÊNCIAS: [023] [1] Bonneau, J., Herley, C., van Oorschot, P. C., & Stajano, F. (2012, May) . The quest to replace passwords: A framework for comparative evaluation of web authentication schemes. In Security and Privacy (SP), 2012 IEEE Symposium on (pp. 553-567) . IEEE. [024] [2] Burr, W. E., Dodson, D. F., & Polk, W. T. (2006). Electronic authentication guideline. NIST Special Publication, 800, 63. [025] [3] Dalton, M,, Kozyrakis, C., and Zeldovich, N., Nemesis: Preventing Authentication & Access Control Vulnerabilities in Web Application, In Proceedings of the 18th conference on USENIX security symposium, (pp. 267-282) USENIX Association. [026] [4] Evans, D., Bond, P., Bement, A., Security Requirements for Cryptographic Modules, FIPS PUB 140-2 - FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION. Online Resource: http://csrc.nist.gov/publications/fips/fipsl40-2/fipsl402.pdf [027] [5] McGloin M. & Hunt P. (2013, January) OAuth 2.0 Threat Model and Security Considerations. ISSN: 2070-1721. Online resource: http://tools.íetf.org/pdf/rfc6819.pdf. [028] [6] Sun, F., Xu, L., & SU,Z. (2011,August) Static detection of Access control vulnerability in web applications. In Proceedings of the 20th USENIX conference on Security (pp. 11-11) . USENIX. [029] [7] Wang, R., Zhou, Y,, Chen, S., Qadeer, S., Evans, D., & Gurevich, Y. (2013) . Explicating SDKs : Uncovering Assumptions Underlying Secure Authentication and Authorization (Vol. 37) . Microsoft Research Technical Report MSR-TR-2013.

DESCRIÇÃO DA INVENÇÃO [030] Para alcançar o mencionado acima, a invenção provê uma solução para evitar diversos ataques relacionados a processos de autenticação e autorização. Essa solução consiste em uma solução que é projetada para limitar o tempo no qual um atacador é capaz de desenvolver um ataque. Portanto, essa solução supõe um limite nos recursos disponíveis a um atacador para organizar e atacar. Primeiro, a invenção visa reduzir o risco de um ataque direcionado a um processo de autenticação/autorização ao bloquear temporariamente o mecanismo de execução de operação. Diminuindo, com isso, o período de exposição desses sistemas e, portanto, diminuindo as chances de sucesso de ataque no sistema. Além disso, um primeiro servidor ou provedor de serviço pode forçar o uso de uma segunda fase de autenticação (utilizando uma infra-estrutura de OTP) para provedores de serviços que não provêem essa opção em seus processos de administração de conta ou mesmo deixam o usuário acioná-la. [031] De acordo com um primeiro aspecto, ê τπ υ'γυχ/ίΙ Ho i ttíí-í t* orlo ί γπτϊ 1 ρ^τπρ^τι f“ a rio nnr ο oram i f- a γ5 ο τ' naTa ρπΐ f*af ataques contra sistemas de autorização, compreendendo: recepção, de pelo menos um primeiro servidor, de uma solicitação no nome de um usuário a ser conectado a um serviço do dito primeiro servidor; e autorização da dita solicitação, pelo dito primeiro sex^vidor, ao verificar informações de identificação de usuário do dito usuário. [032] Ao contrário das propostas conhecidas, e de maneira característica, a fim de a dita solicitação ser autorizada, o método ainda compreende: [033] - envio, pelo dito primeiro servidor a um segundo servidor em conexão com um dispositivo de computação de usuário com um programa dedicado, de uma solicitação sobre um status associado ao dito usuário,- [034] - inicialização de uma troca de credencial entre os ditos primeiro e segundo servidores, a fim de prover autenticação mútua; [035] - verificação do dito status associado que foi previamente estabelecido como válido ou como inválido pelo dito usuário e armazenado em uma memória do dito segundo servidor; [036] - envio, pelo dito segundo servidor, do dito status associado ao dito primeiro servidor; e [037] - utilização, pelo dito primeiro servidor, do dito status associado recebido para: [038] autorizar a dita solicitação para o dito serviço no nome do dito usuário, se o dito status associado for estabelecido como válido, ou [039] rejeitar a dita solicitação para o dito serviço, se o dito status associado for estabelecido como • nvâ-| j Jn X1J. V Ça JL WW f [040] em que, caso a dita solicitação a ser conectada a um serviço do dito primeiro servidor ser autorizada, e uma solicitação ser feita no nome do dito usuário para realizar uma operação no dito primeiro servidor utilizando pelo menos uma parte dos recursos do dito primeiro servidor, o método compreende as seguintes etapas: [041] - realização de uma verificação de status de operação associada ao dito usuário compreendendo uma solicitação de status ao dito primeiro servidor para determinar qual entrada em um esquema corresponde à dita operação; [042] - recepção, pelo dito segundo servidor do dito primeiro servidor, da dita solicitação sobre um status de operação associado ao dito usuário, referente à dita entrada; [043] - inicialização de uma troca de credencial entre os ditos primeiro e segundo servidores; [044] - avaliação, pelo dito segundo servidor, de um status de entrada de esquema de uma raiz para a dita entrada [045] - envio, pelo dito segundo servidor, de um resultado de avaliação ao dito primeiro servidor; [046] - tomada de uma decisão, pelo dito primeiro servidor, ao utilizado pelo menos o dito resultado recebido para permitir ou bloquear a dita solicitação no nome do dito usuário para realizar a dita operação. [047] A solicitação de status associada ao usuário compreende o envio de um token de segurança, o dito token de segurança sendo gerado durante um processo de contas de usuário de pareamento anterior. Esse token liga o usuário ao primeiro servidor sem a revelaçao de quaisquer informações pessoais do usuário para as informações do segundo servidor. Então, o token é armazenado de maneira segura em uma memória do primeiro servidor e em uma memória do segundo servidor, uma vez que o usuário configurou o pareamento das identificações dos primeiro e segundo servidores. [048] A troca de credenciais para autenticação mútua segura entre o primeiro servidor e o segundo servidor é realizada, preferencialmente, por meio de um procedimento de autenticação padrão com base em troca de certificados, definindo, como resultado, um canal seguro. A troca é realizada para verificar que tanto o primeiro servidor como o segundo servidor são quem reivindicam serem. [049] O segundo servidor pode notificar o usuário no caso de a dita solicitação para ser conectado a um serviço do primeiro servidor ser rejeitada. Por exemplo, pelo envio de um Serviço de Mensagem Curta (SMS), de um e-mail, ou de uma mensagem por um aplicativo de envio de mensagem de smartphone, ou somente ao destacar ou promover o dito programa dedicado do dito dispositivo de computação de usuário. [050] Opcionalmente, a etapa de avaliação do status de entrada de esquema, realizada pelo segundo servidor, pode ainda incluir uma autenticação de segundo fator compreendendo, se o dito status de entrada de esquema for estabelecido como válido: [051] - envio, pelo dito segundo servidor, de uma OTP ao primeiro servidor dentro do resultado da operação solicitação de status; [052] - solicitação, pelo primeiro servidor ao usuário, de uma OTP que o usuário utilizará como segundo fator temporal; [053] - envio, pelo segundo servidor, da mesma OTP enviada ao primeiro servidor para o usuário, por meio de outro programa dedicado de usuário; [054] - recuperação, pelo usuário, da dita OTP de segundo fator temporal por meio do dito programa dedicado, introduzindo-a no dito outro programa dedicado de usuário e enviando-a adicionalmente por meio do dito outro programa dedicado de usuário ao primeiro servidor; e [055] - verificação, pelo primeiro servidor, se a OTP recebida do segundo servidor e a OTP de segundo fator temporal recebida do dito outro programa dedicado de usuário corresponde, a fim de permitir ou bloquear a dita solicitação no nome do dito usuário para realizar a dita operação. [056] O status associado é estabelecido como válido (destravado) ou como inválido (travado) por um determinado período de tempo e pode ser passível de modificação pelo usuário sempre que ele desejar. Por exemplo, o usuário pode planejar uma política de travamento/destravamento para automatizar a administração de suas contas mantidas com diferentes servidores utilizando diferentes critérios: tempo, localização geográfica {diferentes políticas para residência, trabalho etc.). Outra possibilidade para modificação do dito status associado pode ser ao delegar o controle que o dito usuário tem de suas contas a outros usuários. Isso pode ser feito ao considerar duas opções diferentes. Na primeira, um mecanismo de controle ΓίλΤΡΐΤΐ" 1 P 11+-1 1 i nara rn i p. ο ΓΌΤ11* ΤθΊ P c\ P r} p Γ*Γ)Υ\ f Ά <a Κμγ W. *4m. V**· J. 4. w- W4. ~J~. Vm* VA V* *&*· .Jm. VA VA V/ Km/ VA. .4«. VA VA VA. Vm# V/ Vm* V»/ Λ* J. V-· «Ji*» VA V«m· VA V#m VA V»* V-* VA V*/ Vm/ VA V*** V** VA Λ. Λ. V* V/v VA de crianças (original) seja delegado ao mecanismo de controle dos nais Na secunda uma única conta oermite múltiolos VA VA kA VA VA 4» A» VA KA V#· .4. VA VA f Wi I. i iVI< vlt* A. V/ Wi Vm· W A 4 w- VA Km/ V* Am ft * U*. V* V# » V V VA A*. V# *4*· IV/ y, w travamentos. Nesse último caso, a ação de destravamento precisará que múltiplos usuários destravem seus travamentos de maneira simultânea. Em ambos os casos, a delegação é realizada de maneira segura, mantendo a privacidade de cada usuário inalterada. [057] Ά solicitação para ser conectado a um serviço e/ou a solicitação para realizar uma operação pode ser registrada a fim de prover dados estatísticos. Dessa forma, o usuário pode obter dados estatísticos de uso do sistema que refletem a atividade do sistema e rastrear as tentativas de representação. Esses dados estatísticos informam sobre quando alguém tentou acessar um serviço com o nome de usuário do usuário. [058] O assunto aqui descrito pode ser implementado em software em combinação com hardware e/ou firmware, ou uma combinação adequada destes. Por exemplo, o assunto aqui descrito pode ser implementado em software executado por um processador. [059] De acordo com outro aspecto, é provido um programa de computador compreendendo meios de código de programa de computador adaptados para realizar as etapas de acordo com o método da reivindicação 1, quando o dito programa for executado em um computador, um processador de sinal digital, uma matriz de porta de campo programãvel, um circuito integrado específico por aplicativo, um microprocessador, um microcontroladores, ou qualquer outra forma de hardware programãvel, [060] As realizações da invenção também englobam um produto de programa de computador incluindo meios de codxgo de programa adaptados para realizar uma autenticação de segundo fator, de acordo com o método da reivindicação 6. [061] A presente invenção permite que o usuário planeje uma política de t ravamento/destravamento para automatizar a administração das contas mentidas com diferentes servidores, utilizando diferentes critérios: tempo, localização geográfica {diferentes políticas para residência, trabalho etc.); delegação do controle de suas contas a outros usuários do dito segundo servidor; habilitação de sistemas de monitoramento que permitem que os usuários sejam alertados de tentativas de furto de identidade ou representação do usuário não real nas solicitações de execução de operação, provisão de um ciclo de ação para obter a ação para controlar a identidade digital; estabelecimento de um segundo fator para autenticação para verificadores que não o estão provendo,· estabelecimento de uma conta a ser bloqueada ou desbloqueada e alteração desta com efeito imediato pelo uso de um controle de alternação; fixação de uma programação para Validar/Invalidar (Bloquear/Desbloquear) uma conta ou a dita operação automaticamente com base nos ajustes de tempo e data. Uma vez que uma solicitação de status verificada é recebida, o segundo servidor responde com base no atual estado do programador; aprimoramento do nível de segurança de uma conta ou da dita operação ao configurar uma autenticação de segundo fator integrada ao segundo servidor; controle de diferentes ações associadas a uma conta, autorização ou proibição da execução destas de maneira compatível com o esquema de autorização estabelecido. [062] Além disso, a invenção permite a homogeneização do nível de segurança para todas as diferentes f** /-'vri +** ώ o /"vi "j "t tyí 11 ai i a ·ν* ι Ή β&ττ*ι Ό ο.τ'ττί i f** tzs /-s a* ύ1*o ο τ ί τ ro τι i rü Ί o X»* XX X X liü* cX XX X** XX111 XX. XX C* X* «X. XX X- XX111 * J* XX Xm 111 «X. Xi" XX XX X» >5 «X. X»* X» JL XX· 111 XX X. V Xz» J* XX vüí segurança comparável ao nivel 4, definido por NIST, E isso ê feito para diferentes contas que podem ser, agora, controladas somente com um dispositivo e independentemente do esquema de autenticação/autorização definido para cada provedor de serviço. [063] A invenção não propõe qualquer esquema de autenticação/autorização novo. De fato, a intenção é complementar os esquemas existentes com uma camada de segurança extra. Embora isso possa limitar sua usabilidade e capacidade de implantação, o projeto da invenção é orientado para minimizar o impacto nesses critérios. Conforme é declarado anteriormente, a escolha do esquema de autenticação determina o risco de segurança que é suposto para um sistema de autorização. O que se propõe aqui é reduzir o risco levado com a escolha de qualquer mecanismo de autenticação/autorização, reduzindo o tempo durante o qual esse sistema está acessível a ser quebrado. [064] Presumindo que haja uma relação entre o sucesso e a falha de um ataque no sistema de autenticação com o tempo no qual esse sistema está acessível (tempo de exposição), uma vez que a probabilidade condicional (p (AtaquedeSucesso | exposto)) é possível determinando que o risco relativo (RR) satisfaz a seguinte expressão: Eq. 1 [065] Nessa expressão, presume-se que a probabilidade de sucesso de um ataque é diretamente relacionada ao tempo de exposição, Isto e, a exposição contínua de um sistema de computador, nesse caso, o sistema de autenticação, aumenta a probabilidade de sucesso de um ataque era contraste a um cenário no qual a exposição ê limitada. Da mesma forma, pode-se avaliar a seguinte expressão: Eq. 2 [066] Indicando que há uma probabilidade maior de um ataque de sucesso, se existir, em exposição contínua de sistemas. Também é possível estimar a parte de todos os ataques de sucesso que poderíam ter sido evitados se a exposição tivesse sido evitada (Porcentagem de Risco Atribuível (ARP)). Isso é calculado com a expressão 3.

Eq. 3 [067] Essa expressão permite a avaliação do investimento necessário para habilitar uma solução projetada para reduzir o tempo no qual o processo de autenticação é acessível. A experiência de profissional e conhecimento técnico das técnicas de ataque documentadas para quebrar sistemas de autenticação/'autorização confirmam a suposição feita anteriormente (RR> 1) . Portanto, pode-se afirmar que ARP> 1, uma vez que o travador de Conta é adotado. [068] Essa redução no tempo de exposição permite diminuir os efeitos da maioria das ameaças relacionada à fase de autenticação, antes de um usuário poder acessar alguns recursos privilegiados. Essa invenção também permite reduzir a exposição de açoes particulares que podem ser tomadas após o processo de registro ter sido realizado. Portanto, essa redução de exposição supõe a limitação no tempo no qual a ação pode ser executada e o estabelecimento de um canal que permite o envio de informações cruciais para garantir a integridade dessa execução de ação. [069] A invenção engloba as soluções para as ameaças definidas por NIST, Mas, nesse caso, essas soluções são providas aos usuários por meio de um programa dedicado, projetado para ser executado em um dispositivo móvel, o que facilita a interação com um segundo servidor. Além disso, esse segundo servidor traz privacidade nas comunicações em relação ao controle das contas de usuário e incorpora todas as informações de controle que os usuários têm de estabelecer sobre as ações que o provedor de serviços oferece a eles.

BREVE DESCRIÇÃO DOS DESENHOS [070] As vantagens e características anteriores e outras serão mais profundamente entendidas a partir da seguinte descrição detalhada das realizações, com referência aos anexos, que devem ser considerados de maneira ilustrativa e não limitante, nos quais: [071] A Figura 1 é uma ilustração da arquitetura geral da presente invenção. [072] A Figura 2 é um fluxograma que ilustra uma sequência de pareamento de conta com autorização. [073] A Figura 3 é um fluxograma que ilustra como um status de uma conta de usuário pode ser verificado para autenticação. [074] A Figura 4 apresenta o fluxograma que resume a maneira que o processo, introduzido na figura 3, r^Orlp· cpr* 'ΓίΏΊΓΡί cn ί a ΠΓί^ΥΙ P* Υ’Ά 1 1 *7. Λ Cl Π MVyWC Ο d» JL d» O w ΚΖίϋ,νΛ J* kJ Ca.X» Cl w vld d***vC? X» Ca JL CaVj». Ca V-/ / CIUU w prOCcSSQ Gt© auwcntlCaÇaO CQIuO QuilGxcl QpeXTdÇcxO uQ Qircl-ΟΓΙΟ nrnnncf*n r>p*1 ο τ*"ϊτ*ιττιρ·ί τό gpηγι γΙοτ* κ-y a, v#/ μ v-/ w- vy ka vy v/ a» -a. íh Vy a- v vy a· v -a- s-a v-y a * DESCRIÇÃO DETALHADA DAS DIVERSAS REALIZAÇÕES [075] Referindo-se â Figura 1, é apresentada a arquitetura geral da presente invenção. Referente à Figura 1, um dispositivo de computação de usuário 100, como um celular, um smartphone, um PC Tablet ou um PDA dentre quaisquer outros, é utilizado pelo dito usuário, a fim de se registrar em um programa dedicado 102 em comunicação com um segundo servidor 200 e para administrar o status para cada primeiro servidor 300 com o qual um usuário deseja solicitar um serviço. [076] Com essa nova proposta, o dito usuário 100 pode desbloquear a dita operação, definida para uma conta em particular, criada com o dito primeiro servidor 300. Conforme declarado abaixo, essa ação pode aprimorar o controle definido para essa conta pela decisão do primeiro servidor 300. Nessa decisão, o primeiro servidor 300 pode escolher incorporar um novo controle de segurança além da opção de bloqueio/desbloqueio padrão ou o segundo fator de autenticação. Esse controle de segurança consiste em prover um canal de comunicação do usuário 100 para o primeiro servidor 3 00, por meio do segundo servidor 2 00. O primeiro servidor 300 pode configurar o sistema para solicitar ao usuário 100 uma informação em particular, relacionada à dita operação a ser realizada. Essa informação pode ser utilizada pelo segundo servidor 200 para verificar se o usuário 100 é quem de fato está solicitando a dita operação e para pnnf i ττπ^τ .qά nnpraran mip phpnnn λλ rn oτ'Λ/'Ί rlnr ^ ΠΠ p» V»»* V»A A A A» A* í 1.1» VA A™ VA V*»»» ««Λ V»A f»A V»»»** A»». V«H» V·»»» VA V»A V»A Tnirti V»v A» A 1*~ Vvf V*»^ V»A VA- V»A r»A A»* -A. i * 1 Nmt* A* «1« VA VA V»v A·* V A». V.A VA A». »»A NA VA exatamente a que o usuário 100 solicitou. [077] Presumindo que o primeiro servidor 300 nnrlPT"! Ά rlpQPn a*r ύ*·'! o irit* ί ri ά rlp» f*| a pSn notip cpr ►A VA VA V-. A» JV M» VAV*»*· kA Va j U Arn V V~* A» A— A». WV A* VA «A» A A V*» V-« V*} A» A~» VA» vi VA Va VA IA VA IA Vv A- VA Vp- IA VA f JfA VA VA Va Va W »J— selecionado quais parâmetros são cruciais para garantir a integridade da operação. Nesse caso, ê importante que as informações solicitadas correspondam, de maneira inequívoca, com o parâmetro crucial de operação, a fim de identificã~lo corretamente. [078] Nessa arquitetura, o usuário 100, além de ter uma conta no segundo servidor 2 00, pode ter múltiplas contas com diferentes provedores de serviços. Um desses provedores de serviços é o primeiro servidor 300. Uma vez que o usuário 100 completa o processo de registro com essas contas, ele/ela terá acesso a múltiplas operações específicas a cada provedor de serviços. O segundo servidor 200 facilita como um primeiro servidor 300 pode integrar esse controle dentro da lógica de seu aplicativo. [079] Quando um primeiro servidor 300 decidir integrar seus serviços, ele proverá a capacidade de ligar suas contas com as contas que o usuário 100 tem no segundo servidor 200. Quando o dito usuário 100 decidir estabelecer essa ligação, ele ou ela começa um processo de pareamento que garante a privacidade completa ao usuário 100. Uma vez que o processo de pareamento está completo, o usuário 100 pode acessar a configuração do controle da conta com o primeiro servidor 300 de um programa dedicado 102 (isto é, um aplicativo de celular). [080] Cada vez que as configurações associadas a uma conta forem alteradas no dito aplicativo de celular, essa modificação é imediatamente propagada ao segundo servidor 200 para alterar o status da conta, que pode ser acessada pelo primeiro servidor 300. [081] Q núcleo do segundo servidor implementa a função principal do segundo servidor 200: travar ou destravar a dita conta de usuário com o primeiro servidor 3 00 e as operações providas pelo primeiro servidor 300. A fim de fazer isso, o segundo servidor 200 aceita e processa as solicitações de status verificadas, enviadas do primeiro servidor 300. Esse segundo servidor 200 também administra todos os dados sobre as ligações com o dito primeiro servidor 300, definidas pelo usuário 100, e as solicitações para o pareamento de novos travamentos. O essencial é nunca serem solicitadas ao usuário 100 quaisquer informações privadas. Uma vez que o usuário 100 cria sua conta com o segundo servidor 200, ele pode estabelecer travamentos com diferentes provedores de serviços, como o dito primeiro servidor 300. Para acionar esses travamentos, o segundo servidor 200, de acordo com uma realização, gera um token. Um token exclusivo e a definição de canais seguros são necessários para concluir o processo de pareamento entre o usuário 100 e o primeiro servidor 300. Como resultado desses processos de pareamento, o token criptográfico é enviado do segundo servidor 200 para o primeiro servidor 300 que armazenou essas informações com seus dados pessoais de usuário. Depois, esse token criptográfico será utilizado para solicitar o status de travamento correspondente. O usuário 100 pode modificar o status de seus travamentos, pela ativação ou configuração das diferentes opções que o segundo servidor 200 provê. [082] No caso de o usuário 100 ter configurado um travamento com um segundo fator para autenticação para uma conta ou uma ação em particular, o segundo servidor 200 nrnrnnTrírá a Ί ocri ra ηρηροο3τ·ί a nara a cfpiracão θ X A V**- V»»/ «L, Jfc»/ Vw/ JL· VA A» VA W Ui CA VA A Vrt> «A» 'w VA A A V«* V»* VA 10 tiif CA A» J» CA jw» CA A» CA VA V·» A» wv Vy* VA V»/ w comunicação da OTP. Quando o segundo servidor 200 receber uma solicitação do primeiro servidor 300, solicitando o status de conta de usuário, um segundo fator de autenticação ê disparado. Uma OTP é gerada e enviada ao usuário 100. A mesma OTP é enviada ao primeiro servidor 300 junto ao status de conta. Se o status for LIGADO e o usuário 100 tiver acionado o segundo fator, o primeiro servidor 300 deve incitar o usuário a introduzir a OTP para proceder com a operação. [083] Agora, se o usuário 100 tiver configurado um travamento na dita operação com um fator de integridade para verificar se os parâmetros de operação não foram modificados, o dito segundo servidor 200 incorpora a lógica necessária para obter as informações cruciais do usuário 100 e do primeiro servidor 300 e para verificar se ambas são iguais. O segundo servidor 200 envia o resultado da verificação como o status de conta ao primeiro servidor 300. No caso de falta de correspondência, o primeiro servidor 300 pode concluir que um intruso pode estar interceptando as informações do usuário 100. O primeiro servidor 300 pode, então, construir mecanismos para enganar a fraude e dar origem à alertas de segurança. [084] Em referência à Figura 2, é ilustrado um processo de pareamento da conta do usuário 100 do segundo servidor 200 com diferentes contas para diferentes primeiros servidores 300. Na Figura 2, uma vez que um usuário 100, que utiliza, por exemplo, o programa dedicado 101, como um navegador, concluiu o processo de registro (A-B) com um primeiro servidor 300 (nesse caso em particular, um Banco on- n p, ΊΊΤΊ1Α τ'λγΙρ' ΡΐοΓ'ίί^Ί sj rip um parfÃn njp t* o tjkm A- J. Vm* jf WtV IH14 wl*. Va VA Va 14# V V# f f*·# A-, VA V VA NA V#* VA V·* Ά V*t* W 111. V#t Wfc 4* V# V#V VA >**4. Va Vi* mV* Va 4» W VA etc,) f o usuário X00 decid© γθη,ΙΙζηγ o dito processo d© Parpampnfn rio rnn f a a O ncnárí n 100 snl í pi t·?! o narAarriprifn an VV *1# Va VA· III V** 4, #* V** Va VA VA Va V** 4· A W1 VA. Va ψ Va VA. V4 VA» VA. V** wJU V# W lw# V-** V* 4. V#. VA. VA P*A ΙΛ Va V4 lll V-** Λ 4* Va W W W primeiro servidor 300 (C) utilizando o navegador 101. Como resposta, o primeiro servidor 300 solicita um token de pareamento (D), 0 usuário 100, então, utiliza o programa dedicado 102 (D' ) para obter esse token de pareamento do segundo servidor 200, apõs um processo de registro anterior. O segundo servidor 2 00 gera um token (por exemplo, como uma OTP) (E) e o envia ao programa dedicado do usuário 102 (F).

Esse token pode ser utilizado para diversos processos de pareamento, enquanto estiver válido. O usuário obtém o token (OTP) do programa dedicado 102 e o introduz na página da web, exibida no navegador 101, pelo primeiro servidor 300 (G-G'). O primeiro servidor 300, então, envia o token recebido ao segundo servidor 200, após uma troca de credenciais anterior (H). Se a identidade do primeiro servidor 300 for validada, o segundo servidor 200 armazena a ligação entre o usuário 100 e o primeiro servidor 300 e gera um novo token que identifica essa ligação. Esse token (ID de conta) é enviado ao primeiro servidor 300 (I) e é armazenado nele para comunicações futuras (J) . Por fim, um reconhecimento de pareamento é enviado ao navegador do usuário 101 (K). [085] Agora, com referência à Figura 3, é ilustrado como um status de uma conta de usuário pode ser verificado para autenticação. Na Figura 3, um usuário 100, que utiliza, por exemplo, um navegador 101, solicita que seja conectado em um serviço (A) de um primeiro servidor 300, assim, uma vez que a existência do usuário foi validada (B) pelo dito primeiro servidor 300, o último solicita ao segundo servidor 200 o status de conta de usuário (C) . Então, o segundo servidor 200 inicializa a troca de credenciais, antes do resultado das informações de status de conta ser enviado (D). Com o status de resultado, o primeiro servidor 300 toma a decisão de permitir ou bloquear o acesso do usuário (E). [086] Em uma realização, se o status de conta for destravado ou válido, mas o segundo fator de autenticação estiver ligado, dentro do pedido da solicitação de status, o segundo servidor 200 envia uma OTP ao primeiro servidor 300 que ele tem de empregar para concluir a autenticação. O primeiro servidor 300, então, solicita ao usuário 100 a OTP que terá de ser um segundo fator temporal (F) . Entãó, o segundo servidor 200 envia a mesma OTP ao programa dedicado do usuário 102 (G). O usuário 100 recupera a OTP do programa dedicado 102 e a introduz no navegador 101 (H) e a envia ao primeiro servidor 300 (I) . O primeiro servidor 300 pode verificar se a OTP enviada por meio do navegador 101 corresponde à recebida com o status de conta (J). Dependendo dos resultados dessa verificação, o primeiro servidor realiza o processo de autenticação (K) e comunica o resultado ao usuário por meio de 101. [087] Quando um primeiro servidor 300 enviar uma Status_Request, o segundo servidor 2 00 entende que alguém, com as informações de identificação de serviço adequadas (isto é, ID e senha), está tentando acessar o serviço. Se o status de conta for enviado como bloqueado ou se essa solicitação vier em um momento no qual não está incluída no intervalo definido pelo usuário 100, o segundo Sp Υ“Λ rí H rj T* 7 Π 0 í cs f- p o C p 1“ O oomn lima ριτη ώ Ί vsa f a 1 e a o segundo servidor 200 poderia enviar, de acordo com uma roa Ί i iittí sa 1 οτΉ a ca cs *sa ο τ' Th f" ao ii cnãvi π cü<s> o .χι 4 a- ™ Çç d «I» «L £λ Ca Yj·· d XX f XX l i l Cl. -1» vÃ X. X* C% XX to to v3 w V X- 11 X» XX Ct XX XX to XX Ca X X XX f to C XX XX X w XX

Ucniari π o \rf& y οο·η ψ »} /-j-t i y = Η o a α α í m í *00 τ'* ρυρπτπ 1 π ao pnvi st nm k»»* VA M. i. hIh V* «I» V W iXf W1 W X X 4m «A* Y"5 VA rim VA VA 'mnf W H»í VA «A» HV \ JW/ Vw» X» V" «* *» V» V l Vfmf -mim V' f WA Vm* V»» XXV «*» VA X» V*. » V V

Claims

1. MÉTODO IMPLEMENTADO POR COMPUTADOR PARA EVITAR ATAQUES CONTRA SISTEMAS DE AUTORIZAÇÃO, compreendendo: recepção, em pelo menos um primeiro servidor (300), de uma solicitação no nome de um usuário (100) a ser conectado a um serviço do dito primeiro servidor (300) ; e autorização da dita solicitação, pelo dito primeiro servidor (300), ao verificar informações de identificação de usuário do dito usuário (100), caracterizado, a fim de que a dita solicitação seja autorizada, pelo dito método ainda compreender: - envio, pelo dito primeiro servidor (300), a um segundo servidor (200), em conexão dom um dispositivo de computação do usuário com um programa dedicado (102), de uma solicitação sobre um status associado ao dito usuário; - inicialização de uma troca de credencial entre os ditos primeiro (300) e segundo servidores (200) , a fim de prover autenticação mútua; verificação do dito status associado que foi anteriormente estabelecido como válido ou como inválido pelo dito usuário (100) e armazenado em uma memória do dito segundo servidor (200); - envio, pelo dito segundo servidor (200), do dito status associado ao dito primeiro servidor (300); e - utilização, pelo dito primeiro servidor (300) , do dito status associado recebido para: o autorizar a dita solicitação no nome do dito usuário, se o dito status associado for estabelecido como válido, ou o rejeitar a dita solicitação, se o dito status associado for estabelecido como inválido. em que, no caso de a dita solicitação ser conectada a um serviço do dito primeiro servidor (300) sendo autorizado e uma solicitação ser feita no nome do dito usuário para realizar uma operação no dito primeiro servidor (300) utilizando pelo menos uma parte dos recursos do dito primeiro servidor (300), o método compreende as seguintes etapas: realização de uma verificação de status de operação associada ao dito usuário (100) compreendendo uma solicitação de status ao dito primeiro servidor (300) para determinar qual entrada em um esquema corresponde à dita operação; recepção, pelo dito segundo servidor (200) do dito primeiro servidor (300), da dita solicitação sobre um status de operação associado ao dito usuário (100) referente à dita entrada; inicialização de uma troca de credencial entre o dito primeiro (300) e segundo servidor (200); avaliação, pelo dito segundo servidor (200), de um status de entrada de esquema de uma raiz para a dita entrada; envio, pelo dito segundo servidor (200), de um resultado de avaliação ao dito primeiro servidor (300) ; tomada de uma decisão, pelo dito primeiro servidor (300), pelo menos ao utilizar o dito resultado recebido para permitir ou bloquear a dita solicitação no nome do dito usuário para realizar a dita operação.

2. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado por compreender notificação, pelo dito segundo servidor (200), ao usuário no caso de a dita solicitação para ser conectado a um serviço do dito primeiro servidor (300) ser rejeitada.

3. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 2, em que a dita notificação é caracterizada por compreender um dentre um envio de um Serviço de Mensagem Curta (SMS), um envio de um e-mail, um envio de uma mensagem por um aplicativo de envio de mensagem de smartphone, um destaque ou promoção no dito programa dedicado (102) do dito dispositivo de computação do usuário.

4. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pelo dito status associado ser estabelecido como válido ou como inválido por um determinado período de tempo.

5. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado por uma segunda autenticação de fator ser utilizada dentro da solicitação do dito status de entrada de esquema se o dito status de entrada de esquema for estabelecido como válido.

6. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 5, em que a dita segunda autenticação de fator é caracterizada por compreender; envio, pelo dito segundo servidor (200) ao primeiro servidor (300), de uma senha de utilização única (OTP); solicitação, pelo primeiro servidor (300) ao usuário (100), de uma OTP que o usuário (100) tem de utilizar como segundo fator temporal; - recuperação, pelo usuário (100), da dita OTP de segundo fator temporal solicitado por meio do dito programa dedicado (102) e, adicionalmente, envio dela ao primeiro servidor (300); e - verificação, pelo primeiro servidor (300), de se a OTP recebida do segundo servidor (200) e a OTP de segundo fator temporal recebida do usuário correspondem, a fim de autorizar ou rejeitar a dita solicitação para o dito serviço no nome do usuário.

7. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 6, em que o primeiro servidor (300) é caracterizado por compreender: permissão da dita operação, se as ditas OTPs corresponderem ou bloqueio da dita operação se as ditas OTPs não corresponderem.

8. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pela dita etapa de avaliação ser realizada para cada etapa encontrada, até atingir a entrada do esquema.

9. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pela dita solicitação, para ser conectado a um serviço, e/ou pela solicitação para realizar uma operação, serem registradas, a fim de prover dados estatísticos.

10. PROGRAMA DE COMPUTADOR, caracterizado por compreender meio de código de programa de computador adaptado para realizar as etapas, de acordo com o método da reivindicação 1, quando o dito programa for executado em um computador, um processador de sinal digital, uma matriz de porta de campo programável, um circuito integrado específico por aplicativo, um micro-processador, um micro-controlador, ou qualquer outra forma de hardware programável.

11. PRODUTO DE PROGRAMA DE COMPUTADOR, de acordo com a reivindicação 11, caracterizado por ainda compreender meio de código de programa para realizar uma segunda autenticação de fator, de acordo com o método da reivindicação 6.