Search

EP-3791533-B1 - PASSWORD BASED THRESHOLD TOKEN GENERATION

EP3791533B1EP 3791533 B1EP3791533 B1EP 3791533B1EP-3791533-B1

Inventors

  • MOHASSEL, PAYMAN
  • AGRAWAL, SHASHANK
  • MUKHERJEE, Pratyay
  • MIAO, Peihan

Dates

Publication Date
20260513
Application Date
20181015

Claims (13)

  1. A method for obtaining an access token by a client (1105), the method comprising: generating a plurality of secret shares, wherein the plurality of secret shares differ from each other; sending the plurality of secret shares to a plurality of servers during a registration process along with a user identifier, wherein to each of the plurality of servers a different secret share from the plurality of secret shares is sent; receiving (1602) a credential for gaining access to a computer resource; hashing (1604) the credential to obtain a first hash; generating a blinded hash of the first hash; sending (1606) request messages to each of a plurality of servers (1112, 1114, 1116, 1118, 1120), each request message including the blinded hash of the first hash and the user identifier; receiving (1608) response messages from each of the plurality of servers (1112, 1114, 1116, 1118, 1120), each response message from a corresponding server including: a partial hash response generated using the blinded hash of the first hash sent to the corresponding server and the secret share sent to the server during the registration process, and an encrypted token share from each of the plurality of servers, the encrypted token share being generated by encrypting a token share using a hash portion that was previously generated by the client and sent to the corresponding server, the hash portion being generated using the first hash and the secret share; deblinding (1610) each of the partial hash responses to obtain the hash portions; decrypting (1612) the encrypted token shares using the hash portions to obtain the token shares; and combining (1614) the token shares to obtain the access token, wherein only a threshold number of response messages are required from the plurality of servers to obtain an access token and the access token grants the client access to a protected resource.
  2. The method of claim 1, further comprising performing a registration with the plurality of servers by: sending requests (1001) to the plurality of servers, each request including the blinded hash of the first hash and the user identifier; receiving responses (1002) from the plurality of servers, each response from a corresponding server and including a corresponding partial hash response generated using the blinded hash sent to the corresponding server and a corresponding secret share; deblinding each of the corresponding partial hash responses to obtain the hash portions; and sending the hash portions to the plurality of servers.
  3. The method of claim 2, wherein the registration includes sending one or more additional hash portions to one or more additional servers.
  4. The method of claim 1, wherein the blinded hash is the same for each of the servers.
  5. The method of claim 1, wherein the blinded hash is different for each of the servers.
  6. The method of claim 1, wherein the token shares and the access token are generated using a non-interactive threshold token generation scheme.
  7. The method of claim 6, wherein the non-interactive threshold token generation scheme is one of: symmetric key based MAC, public key based MAC, secret sharing (Shamir) RSA based digital signature, or pairing based digital signature.
  8. The method of claim 7, wherein the response messages from the plurality of servers (1112, 1114, 1116, 1118, 1120) are received without any further interaction after sending the request messages to the plurality of servers.
  9. The method of any preceding claim, wherein the request messages to the plurality of servers (1112, 1114, 1116, 1118, 1120) are sent in parallel.
  10. A method performed by each of a plurality of server computers (1112, 1114, 1116, 1118, 1120), the method comprising: during a registration process, receiving a secret share and a user identifier, wherein each of the plurality of servers receives a different secret share; receiving (1702) a request message from a client, the request message including a blinded hash of a first hash of a credential and the user identifier; generating (1704) a partial hash response using the blinded hash of the first hash and the secret share received during the registration process; determining (1706) a hash portion corresponding to the user identifier, the hash portion previously received from the client and generated using the first hash and the secret share; generating (1708) a token share based on the user identifier and the secret share; encrypting (1710) the token share using the hash portion corresponding to the user identifier; and sending (1712) a response message to the client, the response message including the partial hash response and the encrypted token share, wherein the client is sent a separate response message from each of the plurality of servers and the encrypted token shares are combinable to obtain an access token such that only a threshold number of response messages are required from the plurality of servers to obtain the access token and the access token grants the client access to a protected resource.
  11. The method of claim 10, further comprising each server computer (1112, 1114, 1116, 1118, 1120) performing a registration with the client by: receiving a request from the client, the request including the blinded hash of the first hash and the user identifier; sending a response to the client, the response including a first partial hash response generated using the blinded hash and the secret share; receiving a hash portion from the client, the hash portion generated by the client by deblinding the first partial hash response; and storing the hash portion in association with the user identifier.
  12. The method of claim 10 or 11, wherein the secret share is received from the client.
  13. A client comprising: one or more processors; and a non-transitory computer readable memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-9.

Description

BACKGROUND Token-based authentication is frequently used to protect and obtain authorized access to resources, services, and applications on the internet and on enterprise networks. There are many ways to perform token-based authentication, with password-based techniques being among the most common. For example, there exist widely-used open standards such as JSON Web token (JWT) and Security Assertion Markup Language (SAML), which facilitate single sign-on authentication by allowing users to initially authenticate using a standard mechanism, such as username/password verification. In return, the users obtain and locally store an authentication token in a cookie or in other local storage of their computing device. Until this token expires, the token may be presented to gain accesses to various applications without any user involvement. Other open standards for token-based authentication, such as Open Authorization (OAuth) and OpenID, utilize a similar mechanism for authentication. Access tokens are issued to users by an authentication server with the approval of the owner of the protected resource. The user may provide the access token to the resource server in order to obtain access to the protected resource without needing any passwords or credentials associated with the resource server. Many companies utilize these open standards to enable their users to share information about their accounts with third party applications or websites without the users having to reveal their passwords. There are also network authentication protocols, such as Kerberos, which take advantage of token-based authentication. These protocols are used by enterprises (e.g. Active Directory in Windows Servers) to periodically, but infrequently, authenticate users with their credentials and issue them a ticket-granting ticket (TGT) that the users can use to request access to various services on the enterprise network, such as printers, internal websites, and more. The typical process flow for token-based authentication may involve a user initially registering a username/password with an authentication server (e.g., by sending a hash of their password to an authentication server). The authentication server stores each user's hashed password and credentials, while also issuing an authentication token for the user based on a master secret key. This token may be generated by computing a digital signature or a message authentication code (MAC) on a message. The user's computing device may receive and store the token, which can be furnished to obtain access to a protected resource. However, the authentication server serves as single point of failure. A malicious attacker that breaches the authentication server may recover the master secret key and forge authentication tokens to gain access to protected resources and information. Furthermore, the attacker may obtain the stored hashed passwords to use as part of an offline dictionary attack to recover user credentials. Although techniques, such as salting and new memory-hard hash functions, exist to deter attackers, such techniques only make it more resource-intensive or difficult for the attackers without fundamentally addressing the problem of having a single point of failure. Accordingly, there exists a need for an approach to token-based authentication that addresses this issue, such that keys and user credentials cannot be compromised (e.g., by an attacker that gains entry to the authentication server). US 5,491,752 describes an improved security system that inhibits eavesdropping, dictionary attacks, and intrusion into stored password lists. In one implementation, the user provides a workstation with a "password" and a "token" obtained from a passive authentication token generator. The workstation calculates a "transmission code" by performing a first hashing algorithm upon the password and token. The workstation sends the transmission code to the server. Then, the server attempts to reproduce the transmission code by combining passwords from a stored list with tokens generated by a second identical passive authentication token generator just prior to receipt of the transmission code. If any password/token combination yields the transmission code, the workstation is provided with a message useful in communicating with a desired computing system. The message is encrypted with a session code calculated by applying a different hashing algorithm to the password and token. In another embodiment, the workstation transmits a user name to the authentication server. The server verifies the user name's validity, and uses an active authentication token generator to obtain a "response" to an arbitrarily selected challenge. The server generates a session code by performing a hashing algorithm upon the response and the password. The server sends the challenge and a message encrypted with the session code to the workstation. The workstation generates the session code by performing the hashing algorit