BR102014015637B1

BR102014015637B1 - METHOD IMPLEMENTED ON COMPUTER TO PREVENT ATTACKS AGAINST USER AUTHENTICATION, AND COMPUTER READABLE MEDIA

Info

Publication number: BR102014015637B1
Application number: BR102014015637-2A
Authority: BR
Inventors: José Maria Alonso Cebrián; David BARROSO BERRUETA; José María Palazón Romero; Antonio GUZMÁN SACRISTÁN
Original assignee: Telefonica Digital Espana, S.L.U.
Priority date: 2013-06-24
Filing date: 2014-06-24
Publication date: 2023-06-06

Abstract

MÉTODO IMPLEMENTADO EM COMPUTADOR PARA PREVENIR ATAQUES CONTRA A AUTENTICAÇÃO DE USUÁRIO E PRODUTO DE PROGRAMA DE COMPUTADOR CARREGÁVEL EM UM SEGUNDO SERVIDOR Um método implementado em computador e produtos de programa de computador para prevenir ataques contra autenticação do usuário. O método implementado em computador compreendendo: recebimento, a partir de um primeiro servidor, de uma solicitação no nome de um usuário a ser logado em um serviço do dito primeiro servidor e autenticando a dita solicitação verificando a informação de identificação do dito usuário, em que um segundo servidor em conexão com um dispositivo de computação do usuário com um programa dedicado é usado para: receber uma solicitação sobre um status associado para o dito usuário; inicialização de uma troca de credencial para prover autenticação mútua; verificação do dito status associado que foi anteriormente estabelecido como válido ou inválido pelo dito usuário; e envio do dito status associado ao dito primeiro servidor, em que o último permite fazer o login da dita solicitação ou rejeitá-la se o dito status associado é estabelecido como válido ou como inválido.COMPUTER-IMPLEMENTED METHOD TO PREVENT ATTACKS AGAINST USER AUTHENTICATION AND COMPUTER PROGRAM PRODUCT LOADABLE ON A SECOND SERVER A method implemented in computer and computer program products to prevent attacks against user authentication. The computer-implemented method comprising: receiving, from a first server, a request on behalf of a user to be logged into a service of said first server and authenticating said request by verifying said user's identification information, wherein a second server in connection with a computing device of the user with a dedicated program is used to: receive a request about an associated status for said user; initiating a credential exchange to provide mutual authentication; verifying said associated status which was previously established as valid or invalid by said user; and sending said associated status to said first server, wherein the latter allows logging said request or rejecting it if said associated status is established as valid or as invalid.

Description

FIELD OF TECHNIQUE

[001] A presente invenção é direcionada em geral a sistemas de autenticação e, mais particularmente, a um método implementado em computador e produtos de programa de computador para prevenir ataques contra a autenticação do usuário que melhora a segurança geral em um sistema de autenticação, minimizando o impacto na capacidade de uso e implementação destes sistemas.[001] The present invention is directed generally to authentication systems, and more particularly to a method implemented in computer and computer program products for preventing attacks against user authentication that improves overall security in an authentication system, minimizing the impact on the usability and implementation of these systems.

BACKGROUND OF THE INVENTION

[002] Nos últimos anos, o mercado de detecção de fraude na web tem aumentado consideravelmente, assim, a inovação nos métodos de autenticação tem se tornado de grande importância.[002] In recent years, the web fraud detection market has increased considerably, thus innovation in authentication methods has become of great importance.

[003] Os sistemas de controle de acesso geral proveem métodos para Autenticação, Autorização e Auditoria (ou Responsabilidade). O processo de autorização é distinto do processo de autenticação. Enquanto autenticação é o processo de verificar se “você é quem você diz que é”, autorização é o processo de verificar se “você tem permissão para fazer o que você está tentando fazer”. Autenticação e autorização são frequentemente combinadas em uma única operação, de forma que o acesso seja concedido com base na autenticação bem-sucedida. Os autenticadores são comumente baseados em pelo menos um dos quatro fatores a seguir: algo que você sabe, algo que você tem, algo que você é e onde você está.[003] General access control systems provide methods for Authentication, Authorization and Auditing (or Accountability). The authorization process is distinct from the authentication process. While authentication is the process of verifying that “you are who you say you are”, authorization is the process of verifying that “you have permission to do what you are trying to do”. Authentication and authorization are often combined into a single operation, so that access is granted based on successful authentication. Authenticators are commonly based on at least one of the following four factors: something you know, something you have, something you are, and where you are.

[004] A arquitetura de segurança vulnerável em muitos aplicativos de computador leva ao problema comum de ataques de hackers a autenticação. Os ataques à autenticação alvejam e tentam explorar o processo de autenticação, um sistema com base em computados usa para verificar a identidade de um usuário, serviço ou aplicação. A Fundação Open Web Application Security Project (OWASP) publicou uma lista completa de ameaças aos métodos de Autenticação mostrando um arranjo de truques, técnicas e tecnologias que existem para roubar senhas, atacar sistemas de senhas e burlar a segurança de autenticação. De acordo com Burr, W, E. et al, [1] esta pode ser estrut Suposição Online lista de ameaças ao processo de autenticação arada nas seguintes categorias: [004] The vulnerable security architecture in many computer applications leads to the common problem of authentication attacks by hackers. Authentication attacks target and attempt to exploit the authentication process, a computer-based system uses to verify the identity of a user, service or application. The Open Web Application Security Project Foundation (OWASP) has published a complete list of threats to Authentication methods showing an array of tricks, techniques and technologies that exist to steal passwords, attack password systems and circumvent authentication security. According to Burr, W, E. et al, [1] this Assumption Online list of threats to the authentication process can be structured into the following categories:

[005] Tabela 1: Categorias de ataques através do Processo de Autenticação (NIST)[005] Table 1: Categories of attacks through the Authentication Process (NIST)

[006] Ê possível implementar uma faixa de contramedidas aos ataques a autenticação descritos acima. Esta invenção propõe uma nova abordagem contra alguns ataques à autenticação que é agnóstico a autenticação, completamente independente de qualquer procedimento de autenticação.[006] It is possible to implement a range of countermeasures to the authentication attacks described above. This invention proposes a new approach against some authentication attacks that is authentication agnostic, completely independent of any authentication procedure.

[007] Existem diferentes alternativas para reforçar os esquemas de autenticação existentes. A segurança na troca de informações é geralmente implementada com SSL/TLS ou EVC/SSL. Mas a maneira que estas informações são selecionadas para serem associadas a uma identidade do usuário pode ser bastante diferente para diferentes esquemas de autenticação. Portanto, é crucial realizar um estudo em profundidade de tais esquemas para revelar seus atalhos. Pode ser estabelecido que, atualmente-, os esquemas com base em dois fatores predominam na maioria dos. sistemas.[007] There are different alternatives to reinforce existing authentication schemes. Security in the exchange of information is usually implemented with SSL/TLS or EVC/SSL. But the way this information is selected to be associated with a user's identity can be quite different for different authentication schemes. Therefore, it is crucial to conduct an in-depth study of such schemes to reveal their shortcuts. It can be established that, currently, two-factor schemes predominate in most cases. systems.

[008] Por exemplo, Bonneau J. et al. [2] propõe a seguinte definição de categorias de procedimentos de autenticação:[008] For example, Bonneau J. et al. [2] proposes the following definition of categories of authentication procedures:

[009] • Esquema Tradicional. Este esquema de segurança depende do usuário. Q usuário deve criar uma senha forte e assegurar que esta não é facilmente comprometida.[009] • Traditional Scheme. This security scheme depends on the user. The user should create a strong password and ensure that it is not easily compromised.

[010] • Base em Proxy. Os esquemas com base em proxy são baseados na definição de um serviço entre o cliente e o servidor (man-in-the-middle) que gerencia o processo de autenticação usando uma senha descartável.[010] • Proxy base. Proxy-based schemes are based on defining a service between the client and the server (man-in-the-middle) that manages the authentication process using a one-time password.

[011] " Autenticação Única Federada. Permitem| que cjs websites deleguem sua identificação de usuário para um) ServidQF de identi-dade confiável que gerencia todo o processo! de aütenticação.[011] " Federated Single Authentication. Allow| that cjs websites delegate their user identification to a) ServerQF of trusted identity that manages the whole process! of authentication.

[012] · GráficQ. Estes esquemas buseam exp1Qrar) a capacidade humana de reconhecer imagens para remover a) nece-'ssidade de senha.[012] · GraphicQ. These schemes seek to exploit the human ability to recognize images to remove a) the need for a password.

[013] • Cognitivo. Estes esquemas são baseados j em desafio/resposta. 0 usuário deve demonstrar seu conhecimento de um segredo sem ter que revelá-lo. Normalmente, o servidor espera que um usuário seja capaz de realizar uma função hash criptográfica do segredo com um número aleatório gerado pelo servidor.[013] • Cognitive. These schemes are challenge/response based. The user must demonstrate his knowledge of a secret without having to reveal it. Typically, the server expects a user to be able to cryptographically hash the secret with a random number generated by the server.

[014] • PaperToken. Usa um armazenamento físico (papel) de um conjunto de senhas indexadas. 0 esquema de autenticação presume que o servidor solicita ao usuário a chave correspondente a um índice específico.[014] • PaperToken. Uses physical (paper) storage of a set of indexed passwords. The authentication scheme assumes that the server prompts the user for the key corresponding to a specific index.

[015] • VisualCrypto. Bastante similar ao paperTokeh, mas com um sistema dé armazenamento de chave complexo que influencia os aspectos do display usado pelo cliente e a maneira na qual os humanos percebem as cores,[015] • VisualCrypto. Very similar to paperTokeh, but with a complex key storage system that influences aspects of the display used by the client and the way humans perceive colors,

[016] • Tokens de Hardware. Os segredos são armazenados em um módulo de hardware que os usuários devem manter com eles. São baseados nos mesmos princípios que os esquemas cognitivos, mas a resposta para o desafio que envia os serviços é provida pelo hardware token do usuário.[016] • Hardware Tokens. Secrets are stored in a hardware module that users must keep with them. They are based on the same principles as cognitive schemes, but the response to the challenge sending services is provided by the user's hardware token.

[017] * Baseado em Telefone. Ê um esquema com base em token, mas em vez de usar um hardware específico para o armazenamento e computação da chave, usa o telefone como o armazenamento de chave e processador do telefone como substituto do hardware criptográfico específico. j[017] * Based on Phone. It is a token-based scheme, but instead of using specific hardware for key storage and computation, it uses the phone as the key store and the phone's processor as a substitute for specific cryptographic hardware. j

[018] • Biometria. Estes esquemas evitam o uso { de senha, baseando a autenticação do usuário em algo que o i define, não somente algo que ele tem ou sabe. J[018] • Biometrics. These schemes avoid the use of a { password, basing the user's authentication on something i defines, not just something i has or knows. J

[019] • Recuperação. Estes esquemas são complementares a qualquer esquema de autenticação com base em senhas, permitindo a recuperação mais fácil da informação necessária para autenticação em caso de perda.[019] • Recovery. These schemes are complementary to any password-based authentication scheme, allowing easier recovery of the information needed for authentication in case of loss.

[020] Ê notável que alguns esquemas de autenticação não pertencem a somente uma categoria e que a maioria das instituições usa pelo, menos dois ou mais destes esquemas, como é o caso do produto Autenticador do Google (ura sistema de autenticação de dois fatores com base em um aplicativo móvel ou mensagem. SMS) .[020] It is notable that some authentication schemes do not belong to only one category and that most institutions use at least two or more of these schemes, as is the case with the Google Authenticator product (a two-factor authentication system with based on a mobile app or SMS message) .

[021] Diferentes critérios podem ser definidos para estabelecer a comparação entre os esquemas de autenticação. Em [21 os autores sugerem a necessidade de definir três critérios a fim de realizar uma comparação eficaz. Estes aspectos são; segurança, utilidade e complexidade na implementação (capacidade de implementação). [2] Apresenta um estudo intensivo para instrumentar a comparação através da definição de métricas. A tabela 2 sumariza as métricas definidas para cada critério. [021] Different criteria can be defined to compare authentication schemes. In [21 the authors suggest the need to define three criteria in order to carry out an effective comparison. These aspects are; security, utility, and implementation complexity (implementation capability). [2] It presents an intensive study to instrument the comparison through the definition of metrics. Table 2 summarizes the metrics defined for each criterion.

[022] Tabela 2: Design de métricas para Esquemas de Autenticação[022] Table 2: Metric Design for Authentication Schemes

[023] No caso do critério de segurança, o conjunto da métrica proposta sumariza todos os aspectos que são normalmente estimados na definição de um modelo de ameaça. Na definição destes modelos, é necessário adotar um número de decisões, definindo estas decisões o cenário de trabalho. Por exemplo, no caso do OAuth 2.0 [3], as suposições adotadas foram as seguintes:[023] In the case of the security criterion, the proposed metric set summarizes all the aspects that are normally estimated in the definition of a threat model. In defining these models, it is necessary to adopt a number of decisions, these decisions defining the work scenario. For example, in the case of OAuth 2.0 [3], the assumptions adopted were the following:

[024] • O hacker tem acesso completo à rede entre o cliente e os servidores de autorização e o cliente e o servidor de recurso, respectivamente. 0 hacker pode aplicar a técnica de eavesdrop em quaisquer comunicações entre estas partes. Ele não é suposto, a ter acesso a comunicação entre o servidor de autorização e o servidor de recurso.[024] • The hacker has complete access to the network between the client and authorization servers and the client and resource server, respectively. The hacker can apply the eavesdrop technique to any communications between these parties. He is not supposed to have access to the communication between the authorization server and the resource server.

[025] • Um hacker tem recursos ilimitados para organizar um ataque.[025] • A hacker has unlimited resources to organize an attack.

[026] • Duas das três partes envolvidas no protocolo OAuth podem conspirar para planejar um ataque contra a terceira parte. Por exemplo, o cliente e o servidor de autorização podem estar sob controle de um, hacker e conspirar para enganar um usuário para obter acesso aos recursos.[026] Two of the three parties involved in the OAuth protocol can conspire to plan an attack against the third party. For example, the authorization client and server may be under the control of a hacker and conspiring to trick a user into gaining access to resources.

[027] Por outro lado, as. senhas têm alta aceitação do cliente, são baseadas em um segredo compartilhado e deve-se ter uma diferente para cada provedor de serviço. 0 problema é que as senhas baseiam-se na memória do usuário e adesão de boas práticas de criação de senha. No entanto.,, evidências de casos mostram que uma parte significante de clientes não seguirá as boas práticas de criação de senha e os ataques normalmente trabalham por meio da obtenção da senha. Isto é uma grave quebra da segurança, já que o hacker é então capaz de operar como o cliente até que a quebra seja descoberta. [[027] On the other hand, as. passwords have high customer acceptance, are based on a shared secret, and should have a different one for each service provider. The problem is that passwords are based on user memory and adherence to good password creation practices. However, case evidence shows that a significant portion of customers will not follow good password creation practices and attacks typically work by obtaining the password. This is a serious breach of security, as the hacker is then able to operate as the client until the breach is discovered. [

[028] Os tokens de hardware são geralmente I considerados para proporcionar uma segurança mais, forte, mas também são suscetíveis a ataques de código malicioso que podem preparar o token para uma solicitação de autenticação, j Os participantes internos autorizados também podem abusar de í seus privilégios e serem capazes de obter chaves criptográficas armazenadas. Os tokens de software têm custos inferiores aos tokens de hardware, mas a desvantagem é que os ataques de simulação tornam-se viáveis.[028] Hardware tokens are generally considered to provide stronger security, but are also susceptible to malicious code attacks that can prepare the token for an authentication request. Authorized internal participants can also abuse their privileges and being able to obtain stored cryptographic keys. Software tokens cost less than hardware tokens, but the downside is that spoofing attacks become viable.

[029] Todos os sistemas de senhas descartáveis precisam ser usados em conjunto com proteções do canal de comunicação. Como a autenticação mútua não é suportada, os ataques de personificação do verificador são possíveis. Isto significa que existe alguma exposição aos ataques de phishing, apesar de o potencial para o sucesso com tais ataques ser muito mais limitado aos sistemas de senha. A exposição a ataques de simulação depende do produto.[029] All disposable password systems need to be used in conjunction with communication channel protections. Since mutual authentication is not supported, verifier impersonation attacks are possible. This means that there is some exposure to phishing attacks, although the potential for success with such attacks is much more limited to password systems. Exposure to simulation attacks is product dependent.

[030] Quando as proteções do canal de comunicação são usadas, até mesmo os esquemas de autenticação com base na biometria são suscetíveis a ataques que simulam os dados, biométricos. Tais ataques são mais prováveis de se tornar mais populares se a biometria for mais amplamente utilizada. Devido a biometria ser dados pessoais, a privacidade é uma questão com relação ao armazenamento, uso e à transferência dos dados biométricos.[030] When communication channel protections are used, even authentication schemes based on biometrics are susceptible to attacks that simulate biometric data. Such attacks are likely to become more popular if biometrics are more widely used. Because biometrics are personal data, privacy is an issue regarding the storage, use and transfer of biometric data.

[031] Em [1] , quatro níveis diferentes são definidos em termos da consequência dos erros de autenticação e uso inadequado das credenciais. O nível 1 é o nível mais baixo (o mais inseguro) e o nível 4 é o mais alto. A partir da tabela 1, a próxima correspondência pode ser feita.[031] In [1] , four different levels are defined in terms of the consequence of authentication errors and improper use of credentials. Level 1 is the lowest (most insecure) level and level 4 is the highest. From table 1, the next match can be made.

[032] • Nível 1 - Proteção contra ataques de suposição e repetição online. NIST recomenda usar uma autenticação única ou de múltiplos fatores sem prova de i identidade.[032] • Level 1 - Protection against online guessing and replay attacks. NIST recommends using single or multi-factor authentication without proof of identity.

[033] • Nível 2 - Proteção contra eavesdropp e todos os ataques do nível 1. NIST recomenda a autenticação única ou de múltiplos fatores.[033] • Level 2 - Protection against eavesdropp and all Level 1 attacks. NIST recommends single or multi-factor authentication.

[034] • Nível 3 - Proteção contra a personificação do verificador, ataques MitM e ataques do nível 2. NIST recomenda uma autenticação de múltiplos fatores e uso amplo do OTP. Também sugere um, token usado para autenticação a ser destravado pelo usuário usando uma senha ou a biometria.[034] • Level 3 - Protection against verifier impersonation, MitM attacks, and Level 2 attacks. NIST recommends multi-factor authentication and extensive use of OTP. It also suggests a token used for authentication to be unlocked by the user using a password or biometrics.

[035] • Nível 4 - Proteção contra hijack e ataques do nível 3. NIST sugere usar a autenticação de múltiplos fatores com hardware FIPS-140-2 resistente a falsificação certificado (tokens de hardware).[035] • Level 4 - Protection against hijack and Level 3 attacks. NIST suggests using multifactor authentication with certified FIPS-140-2 tamper-resistant hardware (hardware tokens).

[036] Tratando das métricas introduzidas acima, é possível determinar que soluções correspondentes ao nível de segurança mais alto (nível 4) tem pouco desempenho, na capacidade de uso e implementação. Uma vez que a avaliação de um sistema permite determinar em qual nível deve ser implementado seu sistema de autenticação, é necessário avaliar se os usuários são autenticados de forma segura e correta. Apesar de existirem algumas ferramentas que ajudam ’ ' I nesta tarefa, como aquelas apresentadas por Dalton, M., et al. [3J ou por Sun, F. et al. [4], implementações no nível 4 ] são difíceis de avaliar corretamente. Em termos de capacidade , de uso, o uso dos tokens de hardware resistentes à falsificação vai contra a adoção destas soluções pelos usuários, e foi provado que esta situação leva a um uso inadequado dos sistemas credenciais. Uma abordagem diferente é necessária para melhorar a segurança geral nos sistemas de autenticação, seja qual for o esquema ou esquemas (múltiplos fatores) adotados, minimizando o impacto na capacidade de uso e implementação destes sistemas.[036] Dealing with the metrics introduced above, it is possible to determine that solutions corresponding to the highest security level (level 4) have poor performance, in terms of usability and implementation. Since the evaluation of a system allows you to determine at which level your authentication system should be implemented, it is necessary to evaluate whether users are securely and correctly authenticated. Although there are some tools that help ’ ' I in this task, such as those presented by Dalton, M., et al. [3J or by Sun, F. et al. [4], implementations at level 4 ] are difficult to evaluate correctly. In terms of usability, the use of counterfeit-resistant hardware tokens runs counter to the adoption of these solutions by users, and this situation has been proven to lead to inappropriate use of credential systems. A different approach is needed to improve overall security in authentication systems, whatever scheme or schemes (multiple factors) are adopted, while minimizing the impact on the usability and implementation of these systems.

REFERENCES:

[037] [1] Burr, W. E. , Dodson, D, F. , & Folk, W. T. (2006). Electronic authentication guideline. NIST Special Publication, 800, 63.[037] [1] Burr, W.E., Dodson, D, F., & Folk, W. T. (2006). Electronic authentication guideline. NIST Special Publication, 800, 63.

[038] [2] Bonneau, J., Herley, C., van Oorschot, P. C. , &. Stajanc, F. (Maio, 2012) . 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.[038] [2] Bonneau, J., Herley, C., van Oorschot, P.C., &. Stajanc, F. (May, 2012). 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.

[039] [3] Michael Dalton, Christos Kozyrakis e Nickolai Zeldovich, Nemesis: Preventing Authentication & Access Control Vulnerabilities in Web Application, In Proceedings of the 18th conference on USENIX security symposium (pp. 267-282) USENIX Association.[039] [3] Michael Dalton, Christos Kozyrakis and Nickolai Zeldovich, Nemesis: Preventing Authentication & Access Control Vulnerabilities in Web Application, In Proceedings of the 18th conference on USENIX security symposium (pp. 267-282) USENIX Association.

[040] [4] Sun, F. , Xu, L. , & SU, Z (agosto de 2011) Static detection of Access control vulnerability in web apllications. In Proceedings of the 20th USENIX conference on Security (pp. 11-11). USENIX.[040] [4] Sun, F. , Xu, L. , & SU, Z (Aug 2011) Static detection of Access control vulnerability in web applications. In Proceedings of the 20th USENIX conference on Security (pp. 11-11). USENIX.

DESCRIPTION OF THE INVENTION

[041] Para alcançar o acima exposto, a invenção provê uma solução: projetada para limitar o tempo de exposição no qual um ataque de autenticação no nome de um usuário pode I ser feito. Portanto, supondo um limite nos recursos disponíveis para realizar o dito ataque, que agora, pelo menos em termos de tempo, podem ser considerados não infinitos.[041] To achieve the above, the invention provides a solution: designed to limit the exposure time in which an authentication attack on a user's behalf can be made. Therefore, assuming a limit on the resources available to carry out said attack, which now, at least in terms of time, can be considered non-infinite.

[042] Para esta finalidade, a invenção provê em ! um primeiro aspecto um método implementado em computador para prevenir ataques contra. a autenticação do usuário, compreendendo receber, de um primeiro servidor, uma solicitação no nome de um usuário a ser logado em um serviço do dito primeiro servidor; e autenticação da dita solicitação, o dito primeiro servidor, por meio da verificação da informação de identificação do usuário do dito usuário..[042] For this purpose, the invention provides in ! a first aspect is a computer-implemented method of preventing attacks against. authenticating the user, comprising receiving, from a first server, a request on behalf of a user to be logged into a service of said first server; and authenticating said request, said first server, by verifying said user's user identification information.

[043] O método implementado em computador do primeiro aspecto compreende, ao contrário das propostas conhecidas, e de uma maneira característica, usar um segundo servidor em conexão com um dispositivo de computação do usuário com um programa dedicado compreendendo: recebimento do dito primeiro servidor uma solicitação sobre um status associado ao dito usuário, que para o usuário conta com o primeiro servidor; inicialização de uma troca de credencial entre os ditos, primeiro e segundo servidores a fim de prover autenticação mútua; verificação do dito status associado que foi previamente estabelecido com válido ou como inválido pelo dito usuário e armazenado em uma memória do dito segundo servidor; e envio do dito status associado ao dito primeiro servidor. Além disso, o método implementado em computador usa : o dito primeiro servidor para: registrar a dita solicitação I no nome do dito usuário se o dito .status associado é i estabelecido como válido ou rejeitar o dito registro se o • dito status associado é estabelecido como inválido.[043] The computer-implemented method of the first aspect comprises, contrary to known proposals, and in a characteristic manner, using a second server in connection with a computing device of the user with a dedicated program comprising: receiving from said first server a request about a status associated with said user, which for the user has the first server; initiating a credential exchange between said first and second servers in order to provide mutual authentication; checking said associated status which was previously established as valid or as invalid by said user and stored in a memory of said second server; and sending said associated status to said first server. Furthermore, the computer-implemented method uses: said first server to: register said request in the name of said user if said associated .status is established as valid or reject said registration if said associated status is established as invalid.

[044] O status associado considerado válido ou inválido pode ser modificável pelo dito usuário sempre que ele quiser. Por exemplo, o usuário pode planejar uma política de bloqueio/desbloqueio para automatizar o gerenciamento das suas contas mantidas com. diferentes servidores usando diferentes critérios: tempo, localização geográfica (diferentes políticas para casa, trabalho etc.). Outra possibilidade para modificar o dito status associado pode ser delegar o controle que o dito usuário tem das suas contas para outros usuários. Isto pode ser feito considerando duas opções diferentes . Na primeira, um mecanismo de controle dos pais é usado de forma que o controle de acesso das contas das crianças (original) seja delegado para o dito mecanismo de controle dos pais. No segundo, uma única conta permite múltiplos bloqueios. Neste último caso, a ação de desbloqueio necessitará que múltiplos usuários desbloqueiem seus bloqueios simultaneamente. Em ambos os casos, a delegação é realizada seguramente mantendo a privacidade de cada usuário não modificada.[044] The associated status considered valid or invalid can be modified by said user whenever he wants. For example, the user can design a lock/unlock policy to automate the management of their accounts held with. different servers using different criteria: time, geographic location (different policies for home, work, etc.). Another possibility to modify said associated status may be to delegate the control that said user has of their accounts to other users. This can be done by considering two different options. In the first, a parental control mechanism is used such that access control of the (original) children's accounts is delegated to said parental control mechanism. In the second, a single account allows multiple blocks. In the latter case, the unlocking action will require multiple users to unlock their locks simultaneously. In both cases, delegation is performed securely while keeping each user's privacy unmodified.

[045] A solicitação de status associada ao dito usuário compreende o envio de um token de segurança, o dito token de segurança sendo gerado durante um processo anterior de pareamento da conta do usuário. Este token liga o Usuário ; ao dito primeiro servidor sem revelar nenhuma informação j pessoal do dito usuário para a dita segunda informação do 4 servidor. Então, o token é seguramente armazenado em uma memória do dito primeiro servidor e em uma memória de um dito segundo servidor, uma vez que o usuário configurou o pareamento da dita primeira e segunda identificação dos servidores.[045] The status request associated with said user comprises the sending of a security token, said security token being generated during a previous pairing process of the user account. This token binds User ; to said first server without disclosing any personal information of said user to said second server. Then, the token is securely stored in a memory of said first server and in a memory of said second server, once the user has configured the pairing of said first and second server identification.

[046] A troca de credenciais para assegurar a autenticação mútua entre o primeiro servidor e o segundo servidor ê realizada, preferencialmente, através de um procedimento de autenticação padrão com base na troca de certificados, definindo, como um resultado, um canal seguro. Como dito anteriormente, a dita troca é realizada para verificar que ambos o primeiro e o segundo servidores são quem eles dizem ser.[046] The exchange of credentials to ensure mutual authentication between the first server and the second server is preferably performed through a standard authentication procedure based on the exchange of certificates, defining, as a result, a secure channel. As stated earlier, said exchange is performed to verify that both the first and second servers are who they claim to be.

[047] Adicionalmente, em uma realização preferida, a etapa de envio do dito status associado ao dito, primeiro servidor pode incluir o envio de um identificador único para o dito usuário, por exemplo, p envio de uma senha descartável (OTP), de forma que um segundo fator de autenticação pode ser ativado pelo dito primeiro servidor ou diversos servidores que não proveem esta opção nos seus processos de login.[047] Additionally, in a preferred embodiment, the step of sending said status associated with said first server may include sending a unique identifier for said user, for example, sending a one-time password (OTP), from so that a second authentication factor can be activated by said first server or several servers that do not provide this option in their login processes.

[048] A dita solicitação recebida pode ser registrada a fim de prover estatística através do dito dispositivo de computação do usuário. Desta maneira, o usuário pode obter estatísticas de uso do sistema que refletem a atividade de sistema e monitoram as tentativas de personificação. Estas estatísticas informam sobre quando alguém tentou acessar um serviço com o nome de usuário do usuário.[048] Said received request may be recorded in order to provide statistics through said user computing device. In this way, the user can obtain system usage statistics that reflect system activity and monitor impersonation attempts. These statistics tell you when someone has tried to access a service under the user's username.

[049] O segundo servidor pode notificar o dito usuário, em outra realização, se a dita rejeição de login ocorrer. Por exemplo, por meio do envio de uma mensagem SMS, i de um e-mail ou de uma mensagem através do aplicativo de I mensagem do smartphone, ou somente pelo destaque ou impulso > em um programa dedicado do dito, dispositivo de computação do usuário.[049] The second server may notify said user, in another embodiment, if said login rejection occurs. For example, by sending an SMS message, an email or a message via the smartphone's message application, or just by highlighting or pushing > in a dedicated program on said user's computing device .

[050] A invenção provê,, em um segundo aspecto, um produto de programa de computador carregável em um segundo servidor para prevenir ataques contra a autenticação do usuário compreendendo diversos módulos de software que são executados no dito segundo servidor para executar as etapas de: recebimento, a partir de um primeiro servidor, de uma solicitação sobre um status associado ao dito usuário; inicialização de uma troca de credencial entre os ditos primeiro e segundo servidores a fim de prover autenticação mútua; verificação do dito status associado, o dito status associado sendo previamente estabelecido como válido ou como inválido por um usuário a partir de um programa dedicado de um dispositivo de computação do usuário, tal como um telefone móvel, um smartphone, um tablet-PC ou um PDA, entre outros dispositivos de computação de características similares, em comunicação com o dito segundo servidor e sendo armazenado em um dos diversos ditos módulos de software; e envio do dito status associado para o dito primeiro servidor.[050] The invention provides, in a second aspect, a computer program product loadable on a second server to prevent attacks against user authentication comprising various software modules that run on said second server to perform the steps of: receiving, from a first server, a request about a status associated with said user; initiating a credential exchange between said first and second servers in order to provide mutual authentication; verification of said associated status, said associated status being previously established as valid or as invalid by a user from a dedicated program of a user's computing device such as a mobile phone, a smartphone, a tablet-PC or a PDA, among other computing devices of similar characteristics, in communication with said second server and being stored in one of several said software modules; and sending said associated status to said first server.

[051] 0 produto de programa de computador pode incluir, em uma realização preferida, um segundo módulo de software de autenticação de fator para envio de um identificador único para o dito segundo servidor e para o dito primeiro servidor.[051] The computer program product may include, in a preferred embodiment, a second factor authentication software module for sending a unique identifier to said second server and to said first server.

[052] A presente invenção não propõe nenhum novo esquema de autenticação. Na verdade, a intenção é complementar os esquemas, listados acima para aumentar sua i segurança. Apesar de isto poder limitar sua capacidade de uso ■ e implementação, o design do segundo servidor é orientado ; para minimizar o impacto sobre estes critérios.. A escolha do i esquema de autenticação determina o risco de segurança que é j suposto para um sistema. O que é proposto aqui é reduzir o risco assumido com a escolha do mecanismo de autenticação, reduzindo o tempo no qual este sistema é acessível para ser burlado.[052] The present invention does not propose any new authentication scheme. In fact, it is intended to complement the schemes listed above to increase your security. Although this may limit its usability and implementation, ■ the second server's design is oriented; to minimize the impact on these criteria.. The choice of authentication scheme determines the security risk that is assumed for a system. What is proposed here is to reduce the risk assumed with the choice of authentication mechanism, reducing the time in which this system is accessible to be circumvented.

[053] Na tabela 1, uma classificação completa dos ataques a autenticação foi apresentada. As primeiras cinco categorias incluem ataques que pretendem capturar uma senha de usuário para realizar um ataque posterior. A suposição online ainda necessita de um acesso constante ao processo de autenticação. Nos próximos quatro ataques, uma vez capturada e burlada a senha, o hacker deve solicitar o processo de autenticação, personificando o usuário falsificado. Este processo é demorado e supõe que o hacker interaja com o sistema de autenticação diretamente. Isto significa que a invenção proposta otimiza o processo de autenticação independente do esquema de autenticação escolhido. Além disso, com o dito segundo fator para autenticação, a invenção concede proteção contra a personificação e os ataques MitM mesmo para serviços que foram implementados somente com a proteção contra a suposição online, ataques de eavesdropp ou repetição. E isto é feito sem aumentar a complexidade da implementação dos sistemas de autenticação e sem uma deterioração signifícante da capacidade de uso da solução. Portanto, esta solução permite homogeneizar os níveis de segurança de diferentes contas de í um usuário.[053] In Table 1, a complete classification of authentication attacks is presented. The first five categories include attacks that intend to capture a user's password to carry out a later attack. Online guessing still requires constant access to the authentication process. In the next four attacks, once the password has been captured and circumvented, the hacker must request the authentication process, impersonating the spoofed user. This process is time consuming and requires the hacker to interact with the authentication system directly. This means that the proposed invention optimizes the authentication process regardless of the chosen authentication scheme. Furthermore, with said second factor for authentication, the invention grants protection against impersonation and MitM attacks even for services that were implemented only with protection against online guessing, eavesdrop attacks or replay. And this is done without increasing the complexity of implementing authentication systems and without significantly deteriorating the usability of the solution. Therefore, this solution makes it possible to homogenize the security levels of different user accounts.

[054] É possível estabelecer certas comparações com as soluções de autenticação, com base em proxy, com j soluções de Autenticação Única Federada ou, ainda, com ; I I soluções com base em telefone. No entanto, em nenhum caso a presente invenção substitui nenhum servidor de autenticação. Com esta solução, qualquer esquema de autenticação seria reforçado por meio da redução do tempo de exposição e, se necessário, expandiria sua funcionalidade permitindo um segundo fator de autenticação se assim solicitado, pelo usuário.[054] It is possible to establish certain comparisons with authentication solutions, based on proxy, with j Federated Single Authentication solutions, or even with ; I I phone-based solutions. However, in no case does the present invention replace any authentication server. With this solution, any authentication scheme would be reinforced by reducing exposure time and, if necessary, expanding its functionality by allowing a second authentication factor if requested by the user.

[055] É verdade qué existe alguma similaridade com soluções móveis que proveem como uma alternativa ao uso de tokens de hardware. No entanto, a necessidade de se ter o telefone ou dispositivo de computação na mão em todos os processos de autenticação é atenuada na presente invenção. Uma vez que o usuário desbloqueou os processos de login para diferentes servidores, estes assim permanecem até que o usuário os bloqueie novamente. Uma vez que o usuário configura um período de tempo quando o serviço deve ser bloqueado, o usuário poderia acessar sua conta ε sempre se fizesse isso fora deste período. Não será necessário que o usuário tenha o telefone na mão para completar o login no sistema, exceto se suas coberturas demandarem um segundo fator para autenticação.[055] It is true that there is some similarity with mobile solutions that provide an alternative to the use of hardware tokens. However, the need to have the phone or computing device in hand for all authentication processes is alleviated in the present invention. Once the user has unlocked login processes for different servers, they remain unlocked until the user locks them again. Once the user configures a period of time when the service should be blocked, the user could access his account ε whenever he did it outside this period. It will not be necessary for the user to have the phone in hand to complete the login to the system, except if their coverage requires a second factor for authentication.

[056] Os sistemas de controle de acesso de recursos são outra comparação que pode ser estabelecida. Estes sistemas normalmente agem como ura "gerenciador de autorização" para permitir usuários a coordenar a proteção dos recursos que são do usuário por meio da definição das políticas associadas a cada recurso. Desta maneira, o usuário controla como fazer o compartilhamento destes recursos com terceiras partes. No caso particular de UMA, propõe-se üm esquema que facilita a centralização destas políticas, UMA também facilita a integração com OpenlD e OAuth, compartilhando vários processos básicos e complementando as funções disponíveis para os usuários para delegação de autenticação e autorização. Uma destas funções básicas é a autorização de uma identidade autenticada. Isto é, para estabelecer mecanismos para autorização previamente, é necessário autenticar usuários. A presente invenção surge, neste ponto, como uma solução que complementa o processo de autenticação antes da autorização, reduz o risco de roubo de identidade e é proposta como uma camada que auxilia estes sistemas de autenticação.[056] Resource access control systems are another comparison that can be drawn. These systems typically act as an "authorization manager" to allow users to coordinate the protection of user-owned resources by defining policies associated with each resource. In this way, the user controls how to share these resources with third parties. In the particular case of UMA, a scheme is proposed that facilitates the centralization of these policies, UMA also facilitates the integration with OpenLD and OAuth, sharing several basic processes and complementing the functions available to users for the delegation of authentication and authorization. One of these basic functions is the authorization of an authenticated identity. That is, to establish mechanisms for prior authorization, it is necessary to authenticate users. The present invention appears, at this point, as a solution that complements the authentication process before authorization, reduces the risk of identity theft and is proposed as a layer that helps these authentication systems.

BRIEF DESCRIPTION OF THE DRAWINGS

[057] As vantagens e aspectos acima e outros serão mais completamente entendidos a partir da descrição detalhada das realizações com referência ao anexo, que deve ser considerado de maneira ilustrativa e não limitativa, no qual:[057] The above and other advantages and aspects will be more fully understood from the detailed description of the achievements with reference to the annex, which must be considered in an illustrative and non-limiting manner, in which:

[058] A Fig, 1 é uma ilustração da arquitetura geral da presente invenção.[058] Fig, 1 is an illustration of the general architecture of the present invention.

[059] A Fig. 2 é uma ilustração do esquema geral do mecanismo de bloqueio da presente invenção, de acordo com uma realização.[059] Fig. 2 is a general schematic illustration of the locking mechanism of the present invention, according to one embodiment.

[060] A Fig. 3 é uma realização de como a presente invenção funciona a fim de realizar um pareamento de conta.[060] Fig. 3 is an embodiment of how the present invention works in order to perform an account pairing.

DETAILED DESCRIPTION OF THE VARIOUS ACHIEVEMENTS:

[061] Em referência à Fig, 1, é mostrada a , arquitetura geral da presente invenção. Em relação à Fig. 1, i um dispositivo de computação do usuário 100, tal como um J telefone móvel, um smartphone, um tablet-PC ou um PDA, entre outros, é usado pelo dito usuário a fim de se fazer o login em um programa dedicado 101 em comunicação com um segundo servidor 200 e gerenciar o status para cada primeiro servidor 300 com o qual um usuário quer solicitar um serviço,[061] With reference to Fig, 1, the general architecture of the present invention is shown. Regarding Fig. 1, a computing device of the user 100, such as a mobile phone, a smartphone, a tablet-PC or a PDA, among others, is used by said user in order to log into a dedicated program 101 at communicating with a second server 200 and managing the status for each first server 300 with which a user wants to request a service,

[062] De acordo com algumas, realizações, o usuário, por meio do dito dispositivo de computação do usuário 100, pode iniciar as contas que tem com diversos servidores 300 com diferentes opções. Por exemplo, o usuário pode fixar um agendamento para bloquear/desbloquear cada conta. É possível agendar qual será o status de serviço para cada dia e cada hora em uma semana ou por períodos de tempo em um ano. Adicionalmente., o usuário também pode melhorar o nível de segurança de um serviço; não somente reduzindo o tempo de exposição, mas configurando um segundo, fator de autenticação, ou pode ainda delegar o controle das suas contas para outro usuário usando o dito programa dedicado 101. Esta delegação é realizada seguramente e mantendo a privacidade de cada usuário não modificada. Somente um ID de identificação é necessário. Finalmente, p usuário pode obter estatísticas de uso do sistema que refletem a atividade de sistema e monitoram as tentativas de personificação,[062] According to some embodiments, the user, through said user computing device 100, can initiate the accounts he has with various servers 300 with different options. For example, user can set a schedule to block/unblock each account. You can schedule what the service status will be for each day and hour in a week or for time periods in a year. Additionally, the user can also improve the security level of a service; not only reducing exposure time, but setting a second authentication factor, or you can delegate control of your accounts to another user using said dedicated program 101. This delegation is performed securely and keeping the privacy of each user unmodified . Only an identification ID is required. Finally, the user can obtain system usage statistics that reflect system activity and monitor impersonation attempts,

[063] Uma Interface de Usuário define uma interface 201 entre os usuários e o segundo servidor 200. Também define e controla a troca de credenciais entre usuários e o segundo servidor 2.00 para construir um canal seguro. Urna vez que este canal é definido, esta interface 201 coiicede a capacidade de criar novos bloqueios no segundo servidor 200. Através desta. interface 201, é possível recuperar a configuração da conta do usuário a partir do segundo servidor 200. E.le permite que o usuário possa modificar esta configuração e obter as estatísticas das suas contas. Também facilita o gerenciamento de um identificador único (tal como uma OTP) a fim de construir a dita autenticação com base no segundo fator.[063] A User Interface defines an interface 201 between users and the second server 200. It also defines and controls the exchange of credentials between users and the second server 2.00 to build a secure channel. Once this channel is defined, this interface 201 grants the ability to create new locks on the second server 200. Through this. interface 201, it is possible to retrieve the configuration of the user's account from the second server 200. It allows the user to modify this configuration and obtain the statistics of his accounts. It also facilitates the management of a unique identifier (such as an OTP) in order to construct said authentication based on the second factor.

[064] Um Gerenciador da Conta do Usuário 2 02 armazena os dados da conta do usuário e implementa o mecanismo de autenticação para identificar e validar o usuário. O mecanismo básico propõe um nome de usuário e/ou um esquema de senha, mas a invenção é projetada para integrar múltiplos fatores para autenticação, como a localização geográfica, construção: de um. perfil das preferências do usuário, biometria etc.[064] A User Account Manager 2 02 stores the user account data and implements the authentication mechanism to identify and validate the user. The basic mechanism proposes a username and/or password scheme, but the invention is designed to integrate multiple factors for authentication, such as geographic location, construction: of one. profile of user preferences, biometrics, etc.

[065] Um Primeiro Gerenciador do Serviço do Servidor 205 armazena informações sobre a comunicação com os ditos primeiros servidores ou diversos servidores 300. Ele gerencia os certificados usados para garantir uma troca segura entre o segundo servidor 200 e o primeiro servidor ou diversos servidores 300. Diversas maneiras de obter estes certificados têm sido implementadas, por exemplo, o segundo servidor 200 pode gerar um certificado válido para um primeiro servidor 300 ou este primeiro servidor 300 pode trazer um. certificado público que o segundo servidor 200 poderia validar.[065] A First Server Service Manager 205 stores information about communication with said first servers or several servers 300. It manages the certificates used to guarantee a secure exchange between the second server 200 and the first server or several servers 300. Several ways of obtaining these certificates have been implemented, for example, the second server 200 can generate a valid certificate for a first server 300 or this first server 300 can bring one. public certificate that the second server 200 could validate.

[066] Um módulo de autenticação de segundo fator 203, no caso de o usuário ter inicializado um bloqueio com um segundo fator para autenticação, de acordo com uma ' realização preferida, incorporará toda a lógica necessária : para a geração e emissão de Uma OTP-por-impulso, OTP-por-SMS > ou OTP-por e-mail. Quando o segundo servidor 200 recebe uma | solicitação do primeiro servidor 300 solicitando o status da ; conta do usuário, um segundo fator de autenticação é acionado. Uma OTP, por exemplo, é gerada e enviada para o usuário. A mesma OTP é enviada para o primeiro servidor 300 com o status da conta. Se o status for "Ligado" e o usuário tiver ativado o segundo fator, o primeiro servidor 300 espera o usuário introduzir a OTP para proceder com o login. Este módulo 2 03. permite a elevação do nível de segurança de uma organização para um nível 3 de acordo çom [1] , conforme foi estabelecido anteriormente.[066] A second factor authentication module 203, in case the user has initialized a second factor lock for authentication, according to a 'preferred embodiment, will incorporate all the necessary logic: for the generation and issuance of an OTP -by-impulse, OTP-by-SMS > or OTP-by email. When the second server 200 receives a | request from the first server 300 requesting the status of the ; user account, a second authentication factor is triggered. An OTP, for example, is generated and sent to the user. The same OTP is sent to the first 300 server with the account status. If the status is "On" and the user has activated the second factor, the first server 300 waits for the user to enter the OTP to proceed with the login. This module 2 03. allows the elevation of an organization's security level to a level 3 in accordance with [1] , as previously established.

[067] Um Núcleo de Bloqueador da Conta 204 implementa a função principal do segundo servidor 20Ò, isto é, bloqueio ou desbloqueio de uma conta do usuário com um primeiro servidor 300. A fim de fazer isso, este módulo 204 aceita e processa as solicitações de status enviadas a partir do primeiro servidor 300. Este módulo 204 também gerencia todos os dados sobre as contas com os ditos outros diversos servidores 300 definidos pelos usuários e as solicitações para o pareamento de novos bloqueios. A chave é o usuário nunca ser solicitado quanto a qualquer informação privada. Uma vez que o usuário cria sua conta corn o dito programa dedicado 101., o usuário pode estabelecer bloqueios com diversos servidores diferentes 300.[067] An Account Blocker Core 204 implements the main function of the second server 20Ò, that is, blocking or unblocking a user account with a first server 300. In order to do this, this module 204 accepts and processes the requests status messages sent from the first server 300. This module 204 also manages all data about the accounts with said other various user-defined servers 300 and the requests for the pairing of new locks. The key is the user is never asked for any private information. Once the user creates his account with said dedicated program 101., the user can establish blocks with several different servers 300.

[068] Para ativar estes bloqueios, o segundo servidor 200 pode gerar um token. Este token e a definição dos canais seguros são usados no processo de pareamento entre o usuário e o primeiro servidor 300. Como um resultado deste ; processo de pareamento, um token, que pode ser criptografado ' para propósitos de proteção, é enviado para o primeiro í servidor 30 que deve armazenar esta informação com seus dados ' pessoais do usuário. Por último, este token será usado, para] solicitar o status de bloqueio correspondente.[068] To activate these locks, the second server 200 may generate a token. This token and the definition of secure channels are used in the pairing process between the user and the first server 300. As a result of this ; In the pairing process, a token, which may be encrypted for protection purposes, is sent to the first server 30 which must store this information with your personal user data. Lastly, this token will be used, to] request the corresponding lock status.

[069] Uma primeira Interface do servidor define uma interface 206 entre o segundo servidor 200 e o primeiro servidor ou diversos servidores 300. Ele define e controla a troca de credenciais entre o segundo servidor 200 e os ditos servidores 300 para construir um canal seguro. Uma vez que este canal é definido, esta interface 206 concede a capacidade de criar novos bloqueios. Define-se um canal para receber e enviar a informação relativa ao status de bloqueios. Também define a maneira que um primeiro servidor 300 pode enviar qualquer informação extra a fim de aumentar as estatísticas oferecidas para os usuários (localização geográfica de onde a tentativa de login foi feita, o IP de onde a tentativa de login foi feita, se o usuário tiver a senha correta etc.).[069] A first server interface defines an interface 206 between the second server 200 and the first server or several servers 300. It defines and controls the exchange of credentials between the second server 200 and said servers 300 to build a secure channel. Once this channel is defined, this interface 206 grants the ability to create new locks. A channel is defined to receive and send information regarding the status of locks. It also defines the way that a first server 300 can send any extra information in order to increase the statistics offered to the users (geographic location from where the login attempt was made, the IP from where the login attempt was made, if the user have the correct password, etc.).

[070] Em referência agora à Fig. 2, um usuário solicita, de acordo com uma realização, ser logado em um serviço (A) de um primeiro servidor 300, assim, uma vez que a existência do usuário tiver sido validada (B) pelo dito primeiro servidor 3 DO, o último demanda para o segundo servidor 20 0 o status da conta do usuário (C) , Então o segundo servidor 200 inicializa a troca de credenciais (D e E) antes da informação do status da conta ser enviada. (F) . Com o status, o primeiro servidor 300 toma a decisão de permitir ou bloquear o acesso do usuário (G).[070] Referring now to Fig. 2, a user requests, according to an embodiment, to be logged into a service (A) of a first server 300, thus, once the existence of the user has been validated (B) by said first server 3 DO, the last demands to the second server 200 the account status of the user (C), then the second server 200 initiates the exchange of credentials (D and E) before the account status information is sent. (F) . With the status, the first server 300 makes the decision to allow or block the access of the user (G).

[071] Quando um primeiro servidor 300 envia um I Request_Status, o segundo servidor 200 entende que alguém com , a informação da identificação do serviço apropriado (isto é, ID e senha) está tentando acessar o serviço. Se o status da conta é estabelecido como bloqueado, ou se esta solicitação vier em um momento que não está incluída no intervalo definido pelo usuário, o segundo servidor 200 registra este j I evento como uma tentativa falsa. O segundo servidor 200 j poderia enviar um alerta deste evento para o usuário se o i dito usuário assim configurá-lo (por exemplo, enviando uma mensagem SMS, um e-mail, uma mensagem por aplicativo de mensagem de smartphone, por meio de um destaque ou impulso no dito programa dedicado 101 do dito dispositivo de computação do usuário 100 etc.) ou somente atualizar as estatísticas para uma revisão posterior. Então o segundo servidor 200 retorna o status associado à conta como bloqueado.[071] When a first server 300 sends an I Request_Status, the second server 200 understands that someone with , the appropriate service identification information (ie ID and password) is trying to access the service. If the status of the account is set to blocked, or if this request comes at a time that is not included in the user-defined interval, the second server 200 logs this event as a false attempt. The second server 200 could send an alert of this event to the user if said user so configured it (for example, sending an SMS message, an email, a message via a smartphone messaging application, through a highlight or push on said dedicated program 101 of said user computing device 100 etc.) or just update statistics for later review. Then the second server 200 returns the status associated with the account as blocked.

[072] Como uma realização exemplar para ilustrar o uso desta invenção, é considerado um usuário que bloqueou o uso do seu cartão de crédito. Este usuário também configurou, por meio do dito programa dedicado ou aplicativo do dispositivo de computação, para receber todos os alertas de tentativa de login falhas como um SMS no seu dispositivo de computação (isto é, um telefone móvel). Por outro lado, uma vez que o segundo servidor, também chamado de Bloqueador de Conta, notifica o primeiro servidor ou Provedor de Serviço (neste caso que emitiu o cartão de crédito) que o usuário legítimo desta conta bloqueou o serviço, ele pode, por sua vez, começar as ações imediatas para preservar seus ativos contra tentativas de fraude (por limites de crédito, monitoramento deste serviço etc.).[072] As an exemplary embodiment to illustrate the use of this invention, it is considered a user who blocked the use of his credit card. This user has also configured, via said dedicated program or application on the computing device, to receive all failed login attempt alerts as an SMS on their computing device (ie mobile phone). On the other hand, once the second server, also called Account Blocker, notifies the first server or Service Provider (in this case that issued the credit card) that the legitimate user of this account has blocked the service, he can, for in turn, start immediate actions to preserve your assets against fraud attempts (by credit limits, monitoring of this service, etc.).

[073] Em outra realização^ em referência à ; Fig.3, é mostrado o processo de pareamento da conta do ; usuário do segundo servidor 200 com contas diferentes para ’ diferentes servidores 300, Na Fig. 3, uma vez que um usuário, ' usando, por exemplo, um browser 100, tiver completado o ; processo de login (A-B) com um primeiro servidor (neste caso particular, um banco online, uma rede social, provedores de cartão de crédito etc,), o usuário decide realizar o dito processo de pareamento das contas.. O usuário solicita o pareamento ao dito primeiro servidor 3.00 (C). . Como resposta, o primeiro servidor 300 solicita um token de pareamento (D). i 0 usuário então usa o programa dedicado 101 (D') para obter este token de pareamento a partir do segundo servidor 200 (E) , após um processo de login anterior. 0 segundo servidor 200 gera um token (por exemplo, como uma OTP) e o envia para o programa, dedicado do usuário 101 (F) . Este token pode ser usado para diversos processos de pareamento enquanto é válido. 0 usuário obtém o token (OTP) a partir do programa dedicado 101 e o introduz na página da web exibida no browser 100 pelo primeiro servidor 300 (G-G'). Or primeiro servidor 300 então envia o token recebido para o segundo servidor 200, após uma troca, de credenciais anterior (H) , Se a identidade do primeiro servidor 300 é validada, o segundo servidor 200 armazena o link entre o usuário e o primeiro servidor 300 e gera um novo token que identifica este link. Este token (Usuário/Primeiro Servidor) é enviado para o primeiro servidor e é armazenado para comunicações futuras (I). Finalmente, um reconhecimento de pareamento é enviado para o browser do usuário 10 0 (J) . ;1[073] In another embodiment^ in reference to ; Fig.3, the account pairing process is shown; second server user 200 with different accounts for different servers 300, In Fig. 3, once a user, ' using for example a browser 100, has completed the ; login process (A-B) with a first server (in this particular case, an online bank, a social network, credit card providers, etc.), the user decides to carry out said account pairing process.. The user requests the pairing to said first server 3.00 (C). . In response, the first server 300 requests a pairing token (D). The user then uses the dedicated program 101(D') to obtain this pairing token from the second server 200(E) after a previous login process. The second server 200 generates a token (eg as an OTP) and sends it to the dedicated user program 101(F). This token can be used for multiple pairing processes while it is valid. The user obtains the token (OTP) from the dedicated program 101 and inputs it into the web page displayed on the browser 100 by the first server 300 (G-G'). The first server 300 then sends the received token to the second server 200, after a previous exchange of credentials (H), If the identity of the first server 300 is validated, the second server 200 stores the link between the user and the first server 300 and generates a new token that identifies this link. This token (User/First Server) is sent to the first server and is stored for future communications (I). Finally, a pairing acknowledgment is sent to the user's browser 100(J). ;1

[074] A presente invenção seria útil também ) para autorizar operações, tal como transações para um pagamento eletrônico, entre outros muitos exemplos. Neste caso particular, o método e sistema propostos seriam estendidos. Por exemplo, o primeiro servidor 300, em vez de receber uma solicitação no nome de um usuário a ser logado em um serviço do primeiro servidor, receberá uma solicitação a fim de realizar uma operação nele, na qual a dita solicitação será autorizada pelo primeiro servidor 300. Então, após o segundo servidor 200 executar suas tarefas comuns (isto é, a inicialização da troca de credencial, a verificação do status associado etc.) conforme executadas nas realizações anteriores, o primeiro servidor 300 pode autorizar a dita solicitação ou rejeitá-la, dependendo do status associado provido pelo usuário, consequentemente provendo um mecanismo mais seguro para operações de autorização.[074] The present invention would also be useful ) to authorize operations, such as transactions for an electronic payment, among many other examples. In this particular case, the proposed method and system would be extended. For example, the first server 300, instead of receiving a request on behalf of a user to be logged into a service of the first server, will receive a request in order to perform an operation on it, in which said request will be authorized by the first server 300. Then, after the second server 200 performs its common tasks (ie, initiating the credential exchange, checking the associated status, etc.) as performed in the previous realizations, the first server 300 can either authorize said request or reject it. la, depending on the associated status provided by the user, hence providing a more secure mechanism for authorization operations.

[075] O escopo da presente invenção é definido no quadro reivindicatório a seguir.[075] The scope of the present invention is defined in the set of claims below.

Claims

1. METHOD IMPLEMENTED ON A COMPUTER TO PREVENT ATTACKS AGAINST USER AUTHENTICATION, the method comprising: - receiving, by a first server (300), from a user, a request to be logged into a service of said first server (300), said request including providing identifying information validating the user's identity at the first server (300); and - authentication, by said first server (300), of said user identification information in order to authorize said service registration request, characterized by: - using a second server (200) in connection with a computing device (100) of the user, through a dedicated program (101) installed on the computing device (100) of the user, to manage a status of the accounts that the user has on the first server (300), in which the status of the accounts are adjusted as valid or invalid by the user through the dedicated program (101) and stored in a memory in the second server (200), after a secure channel between the second server (200) and the computing device (100) is defined, and where said secure channel is defined after an exchange of credentials between the second server (200) and the user is performed; - receiving, by the second server (200), from said first server (300) a request about a status relating to a user account on the first server (300); - in response to receiving the request, initialize, by the second server (200), a credential exchange with the first server (300) in order to provide mutual authentication, the exchange of credentials being carried out through an authentication procedure with based on exchanging certificates between the first server (300) and the second server (200); - verifying, by the second server (200), said account status; and - sending, by said second server (200), said account status to the first server (300), the latter using the received account status to authorize said registration request to the service if said account status is established as valid, or - reject said service registration request if said account status is established as invalid.

2. METHOD IMPLEMENTED ON A COMPUTER, according to claim 1, in which said request regarding the status of the account is characterized by comprising the sending of a security token, said security token being generated during a previous pairing process of the user account.

3. COMPUTER-IMPLEMENTED METHOD, according to claim 2, characterized in that it further comprises storing said generated security token in said memory and in a memory of said first server (300).

4. COMPUTER-IMPLEMENTED METHOD, according to claim 3, characterized in that said security token is sent encrypted to said first server (300).

5. COMPUTER-IMPLEMENTED METHOD, according to claim 1, characterized in that the step of sending said account status to said first server (300) includes sending a unique identifier for said user.

6. METHOD IMPLEMENTED ON A COMPUTER, according to claim 1, characterized in that it comprises notifying said user if said request to log into a service of said first server (300) is rejected.

7. METHOD IMPLEMENTED ON A COMPUTER, according to claim 6, in which said notification is characterized by comprising one of sending a Short Message Service (SMS), sending an e-mail, sending a message by a smartphone messenger application, a highlight or push in the dedicated program doto (101) of said user's computing device.

8. COMPUTER-IMPLEMENTED METHOD, according to claim 1, characterized in that said received request is recorded in order to provide statistics through said user computing device.

9. METHOD IMPLEMENTED ON A COMPUTER, according to claim 1, characterized in that said account status established as valid or invalid is modifiable.

10. COMPUTER-IMPLEMENTED METHOD, according to claim 1, characterized in that said account status is established as valid or invalid for a certain period of time.

11. COMPUTER READABLE MEDIA STORING COMPUTER EXECUTABLE INSTRUCTIONS, characterized by performing the steps of: - managing and storing a status of the accounts that a user has on a first server (300), said status being received from a dedicated program (101) installed in a computing device (100) of the user and the status being set as valid or as invalid by the user through the dedicated program (101); - receiving from a first server (300) a request about a status relating to a user account on the first server (300); - initializing a credential exchange with the first server (300) in order to provide mutual authentication, the exchange of credentials being carried out through an authentication procedure based on the exchange of certificates between the first server (300) and the second server (200); - check said account status; and - sending said account status to said first server (300) in order to allow the first server (300) to use the received account status to authorize or deny the user to log into the service of the first server (300).

12. COMPUTER READABLE MEDIA, according to claim 11, characterized in that it comprises a second factor software module (203) for sending a unique identifier to said second server (200) and to said first server (300) .

13. COMPUTER READABLE MEDIA according to claim 11, characterized in that said user computing device (100) is a mobile phone, a smartphone, a tablet-PC or a PDA.