WO2024079340A1 - Method for securely manipulating a password hash, a client-server system involving the same, and methods for securing a user-provided password in a client for recovery only by an authentication server - Google Patents

Method for securely manipulating a password hash, a client-server system involving the same, and methods for securing a user-provided password in a client for recovery only by an authentication server Download PDF

Info

Publication number
WO2024079340A1
WO2024079340A1 PCT/EP2023/078546 EP2023078546W WO2024079340A1 WO 2024079340 A1 WO2024079340 A1 WO 2024079340A1 EP 2023078546 W EP2023078546 W EP 2023078546W WO 2024079340 A1 WO2024079340 A1 WO 2024079340A1
Authority
WO
WIPO (PCT)
Prior art keywords
password
client
server
user
hash
Prior art date
Application number
PCT/EP2023/078546
Other languages
French (fr)
Inventor
Francisco Blas IZQUIERDO RIERA
Jose Ernesto SUAREZ FONT
Pierre-Louis François Christian RAUST
Original Assignee
Garmer Technologies OÜ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Garmer Technologies OÜ filed Critical Garmer Technologies OÜ
Publication of WO2024079340A1 publication Critical patent/WO2024079340A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • G06F21/46—Structures or tools for the administration of authentication by designing passwords or checking the strength of passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN

Definitions

  • exfiltrated credentials or exfiltrated hashed credentials can allow the attacker(s) to impersonate other devices and servers across a network.
  • This is problematic on Industrial Internet of Things (IIoT) networks that frequently use a single low entropy password shared across devices.
  • IIoT Industrial Internet of Things
  • the impact of exfiltrated passwords enabling further exploitation on a network further raises a challenge on protecting stored passwords after a compromise, from e.g. dictionary attacks, while ensuring that knowledge of the password still suffices for authentication purposes.
  • This challenge cannot be resolved by the server side because the server needs to authenticate the client and, for password-based authentication, cannot expect the client to keep additional data to protect the verifiers stored by the server.
  • password security relies heavily on the choice of password by the user.
  • passwords can be stored after using a one-way hash.
  • Password hashing is a security measure that converts passwords into illegible strings of characters, known as hash.
  • a common way to secure such hashes is by using computationally expensive hash function(s) that has been made more complex in terms of computational power and memory requirements to compensate for the increased computing power of attackers.
  • an attacker can still perform unlimited password guesses in parallel once these hashes are leaked out.
  • attackers may recover stored password hashes. These hashes may then be cracked and used on other services where the same or similar passwords may have been reused.
  • Techniques like salted hashes ensure that an attacker needs to attack each user’s password individually.
  • a salt is a piece of text added (usually prepended) to a password before hashing. Salts can be public and create unique password hashes even if two users choose the same password. When verifying the password, the salt is fetched or reconstructed, prepended to the password, hashed using the same algorithm and then compared against the stored entry. Salted hashes increase the search space linearly with the number of users. However, attackers can make use of devices, such as graphics processing units (GPUs), field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), that can perform a huge number of guesses per second and per watt.
  • GPUs graphics processing units
  • FPGAs field-programmable gate arrays
  • ASICs application-specific integrated circuits
  • a method for securely manipulating a password hash may include executing, by a client associated with a user, a SALT generation function to provide a globally unique SALT value, wherein the client is part of a client-server system; and combining, by the client, the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password of the user.
  • a non-transitory computer readable storage media are provided.
  • a client-server system may include a client configured to execute a SALT generation function to provide a globally unique SALT value and combine the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password of a user, wherein the client is associated with the user; and a server configured to receive the password hash from the client.
  • a method for securing a user-provided password in a client for recovery only by an authentication server may include providing, by the client, a password hash obtained from a method according to an embodiment or by using a lightweight hash of the user-provided password; generating and storing, by a server, a public key and a private key; receiving, from the server by the client, the public key; encrypting, by the client, the password hash based on the public key to obtain an encrypted password hash; storing, by the client, the encrypted password hash in a storage medium; receiving, from the client by the server, the encrypted password hash and optionally the username; and authenticating the client as the user by the authentication server.
  • the encrypted password hash may be optionally associated with a username of a user and an identifier of the server.
  • the step of authenticating the client may include decrypting the encrypted password hash using the stored private key; optionally hashing the decrypted password hash using a hashing function; and determining that the decrypted password hash or the optionally hashed decrypted password hash is the same as a value associated with the password hash previously stored in a database accessible by the server.
  • a method for securing a user-provided password in a client for recovery only by an authentication server is provided. The method may include providing a registration process, providing a setup process, providing a provisioning process, and providing an authentication process.
  • the registration process may include obtaining, by the client, the user-provided password of a user and optionally a username of the user; and associating a value with the user-provided password.
  • the setup process may include generating and storing, by a server, a public key and a corresponding private key.
  • the provisioning process may include receiving, from the server by the client, the public key; encrypting, by the client, the user-provided password based on the public key to obtain an encrypted password value; storing, by the client, the encrypted password value in a storage medium.
  • the encrypted value may be associated with the username and an identifier of the server.
  • the authentication process may include retrieving, from the client, the stored encrypted password value; receiving, from the client by the server, the retrieved encrypted password value and optionally the username; decrypting the retrieved encrypted password value using the stored corresponding private key to obtain a decrypted value; and determining that the decrypted value is the same as the value associated with the user- provided password.
  • FIG. 1 shows a flow chart illustrating a method for securely manipulating a password hash, according to various embodiments.
  • FIG.2 shows a schematic representative view of a client-server system involving secure manipulation of a password hash, according to various embodiments.
  • FIG. 3 shows a flow chart illustrating a method for securing a user-provided password in a client for recovery only by an authentication server, according to various embodiments.
  • FIG.4 shows a schematic representation of the concept of Clipaha, according to an embodiment.
  • FIG.5 shows a schematic representation of an existing server-side hashing (prior art), according to an example. [0023] FIG.
  • FIG. 6 shows a flow chart illustrating a method for securing a user-provided password in a client for recovery only by an authentication server, according to other embodiments.
  • Detailed Description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be utilized and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various embodiments are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. [0025] Embodiments described in the context of one of the methods or devices are analogously valid for the other methods or devices.
  • the phrase “at least substantially” may include “exactly” and a reasonable variance.
  • the term “about” or “approximately” as applied to a numeric value encompasses the exact value and a reasonable variance.
  • the term “and/or” includes any and all combinations of one or more of the associated listed items.
  • the phrase of the form of “at least one of A or B” may include A or B or both A and B.
  • the phrase of the form of “at least one of A or B or C”, or including further listed items may include any and all combinations of one or more of the associated listed items.
  • Various embodiments relate to Information Technology (IT) protocols, more specifically, methods for securely offloading password hashing to a client.
  • Client-side password hashing or abbreviated as Clipaha, provides a system and a method to perform password stretching on the client, while addressing security issues found in existing work.
  • Clipaha is robust to a broader range of attacks compared to existing work and covers important and complex usage scenarios. Clipaha is readily deployable on both embedded devices as well as systems (e.g. highly constrained server devices) with complex authentication requirements such as database migrations or accounts identified by multiple usernames.
  • Clipaha does not compromise on the security compared with server-side approaches and allows stronger user authentication in highly-constrained devices. This may be evident by its demonstrated security, an analysis on how to it may be used to securely implement basic and complex authentication related flows, provision of a working implementation, a successful deployment on an embedded device possibly with limited resources such as in an ESP8266 (an embedded wireless device popular on Do It Yourself (DIY) environments featuring an 80 MHz processor and 80 KiB of memory for user data), a benchmark of the resulting code on several classes of hardware and software involving different systems to understand the limitations of mixed Javascript and Webassembly approach faces.
  • ESP8266 an embedded wireless device popular on Do It Yourself (DIY) environments featuring an 80 MHz processor and 80 KiB of memory for user data
  • FIG. 1 shows a flow chart illustrating a method 100 for securely manipulating a password hash, according to various embodiments.
  • a SALT generation function may be executed, by a client associated with a user, to provide a globally unique SALT value, wherein the client (e.g. 212 of FIG. 2) is part of a client- server system (e.g.210 of FIG.2).
  • the globally unique SALT value may be combined with a password hashing function, by the client, to generate and provide the password hash of a user-provided password of the user.
  • the step of executing the SALT generation function may include generating the globally unique SALT value including a globally unique system identifier of the client-server system, and optionally a username of the user.
  • the username may not be included in the globally unique SALT value if only one password exists.
  • the step of generating the globally unique SALT value may include delimiting the globally unique system identifier.
  • the step of executing the SALT generation function 104 may include combining a globally unique system identifier of the client-server system with a username of the user to generate the globally unique SALT value.
  • provision of the username may be optional.
  • the client may choose not to send the username and the server may check for the presence of the password hash and optionally associate the username or an authentication entity associated with the username on the database, if any, to the client.
  • the step of combining the globally unique system identifier and the username may include delimiting the globally unique system identifier, or the username, or both the globally unique system identifier and the username.
  • the method 100 may further include prior to executing the SALT generation function at Step 102, canonicalizing the username.
  • the term “manipulating” may be referred to as generating, using, modifying, configuring, or implementing.
  • the term “combining” may mean and is not limited to prepending, appending, or mixing.
  • client refers to a device, computer, or software program that connects to and uses the resources of a remote computer or server.
  • a user may use a client to gain access to these remote resources.
  • the client may be associated with the user by being at the user’s end.
  • the user may use the client to create or log into a user account for a service in a network.
  • the user may be an actual owner of the user account, or any other entity that tries to access the account.
  • the user may be a human or a non-human, e.g. an artificial intelligence (AI) system, a sensor, or an actuator.
  • AI artificial intelligence
  • the user may be a basic identification entity in the context of who or what the client says to be.
  • the method 100 may be based on the concept of client-side password hashing (Clipaha) and provide a Clipaha salt generation function.
  • FIG.4 shows a schematic representation of the concept of Clipaha that is in comparison to a schematic representation of an existing server- side hashing as seen in FIG.5.
  • a secure one-way function protects stored passwords (e.g., a cryptographic hash) ⁇ (. ) including a random salt s prepended to the password p to make the password unique and avoid equal passwords from being easily recognized during dictionary attacks. As shown in FIG.
  • the triplet ⁇ ⁇ , ⁇ , ⁇ ( ⁇ ⁇ ⁇ ) ⁇ is stored in the server database, so the hash function has to be computed at every access.
  • the complexity of the hash functions has increased.
  • Clipaha moves the resource-intensive hash function ⁇ ( ⁇ ⁇ ⁇ ) to the client, denoted as ⁇ ( ⁇ ⁇ ⁇ ) in FIG. 4.
  • the salt s ⁇ is not a random string generated and maintained by the server but instead, is a deterministic string derived from the username u and a globally unique string, e.g. the server’s domain name.
  • the server (e.g.214 of FIG. 2) only has to compute a low-cost hash function h(. ), e.g. SHA-256, to prevent replay attacks of leaked password database entries and direct use of leaked database entries to access the server.
  • h(. ) e.g. SHA-256
  • the low complexity of computation, communication, and storage at the server allows Clipaha to run on embedded devices.
  • the method 100 may efficiently and securely move password hashing to a client to solve the issue of storing password hashes, while requiring (a) a salt value globally unique to both user and the system, and (b) knowledge of the hash function to use and the parameters to use it with.
  • the method 100 is able to move the password hashing step to the client without introducing new security risks in the process and encrypting client-stored hashes in a way that only the targeted server is able to recover them.
  • the solution offers hash parameters known at compilation time, uses only user-provided or non-user specific server-provided data for computation, and enables complex use-cases like database migration or password storage to be implemented on the client for later use.
  • the method 100 may further include encoding, by the client, the password hash by using at least one of: compile-time hash function parameters, single-instruction-multiple- data (SIMD) or prefetch instructions.
  • compile-time hash function parameters may be used and this significantly improves the performance of the resulting hash function.
  • SIMD instructions and prefetch instructions in the target language may also be used to improve performance even more.
  • the method 100 may further include sending, by the client to a server (e.g.214 of FIG.2) of the client-server system (e.g.210 of FIG.2), registration information provided by the user, the password hash, and optionally, the user-provided password, wherein the registration information include the username; optionally validating, by the server, the registration information and optionally the user-provided password; and storing, in a database accessible by the server, the password hash along with the username and optionally the registration information.
  • a registration process may be performed.
  • the method 100 may further include receiving, by a server of the client-server system, the password hash; hashing, by the server, the password hash by using a hashing function to obtain a server-hashed password hash; and comparing, by the server, the server-hashed password hash and a validator placed in trust of the server to obtain an indicator, wherein based on the indicator, the server associates with the user to authenticate an identity of the user.
  • the validator may be kept anywhere the server trusts.
  • the method may further include hashing the (user-provided) password hash on the server using the hashing function and then comparing the result with that, the server associates with the provided user.
  • the hashing function may include a lightweight hashing function, or a keyed hashing function.
  • the method 100 may further include performing multi-factor authentication to provide an additional proof of the identity of the user, or a password authenticated key exchange to verify the password hash to mutually authenticate the client and the server, or a hybrid exchange to authenticate the client by verifying the client’s knowledge of the user- provided password, and the server by using a way other than the server’s knowledge of the user-provided password.
  • the way other than the server’s knowledge of the user-provided password may involve a private key or a certificate.
  • the method 100 may further include combining, by the client, the globally unique SALT value with the password hashing function to generate and provide a replacement password hash of a replacement user-provided password; additionally receiving, by the server, the replacement password hash; optionally receiving, by the server, the replacement user-provided password, or the user-provided password, or the username; and upon successfully authentication of the identity of the user, storing, in a database accessible by the server, the replacement password hash in place of the password hash stored in the database, consequently performing a change of password.
  • the replacement user-provided password and the user-provided password may be optional and may only be needed if the server needs to perform password policy check.
  • password policy check may involve ensuring that the new (replacement) password has not been used before.
  • the requestor for the password change needs to be verified as who the requestor says to be because the requestor may be authenticated earlier and this can be verified, or because the requestor may be authenticated on the spot by providing the hashed password.
  • the server minimally requires the replacement password hash and the indicator of a valid authentication (or the like, e.g. a session identifier for stateless protocols, a valid session for stateful protocols, or the password hash optionally with the username).
  • the Secure Shell (SSH) Protocol may mark the connection as authenticated and associate the user information to it which defacto authenticates any future requests over the connection.
  • SSH Secure Shell
  • http Hypertext Transfer Protocol
  • a cookie may be set to allow identifying future requests since http is stateless.
  • http makes the client send the cookie value on future requests to prove its identity.
  • CSRF Cross-Site Request Forgery
  • CSRF Cross-Site Request Forgery
  • the method 100 may further include caching, by the client, the password hash.
  • the method 100 may further include decryption of the user-provided password (hashed or not) to optionally hash the decrypted data on the server using a password hashing function, and then compare the result with that the server associates with the provided user.
  • Various embodiments may provide one or more non-transitory computer readable storage media each having stored thereon at least part of a processor-executable software instruction set, wherein the processor-executable software instruction set is configured to cause one or more processors to execute a method 100 for securely manipulating a password hash, in accordance with various embodiments.
  • the one or more non-transitory computer readable storage media may store codes for functions run on the client, that may be (but are not limited to being) stored on the client, or in a cache from a prior execution. It should be appreciated that codes for functions run on the client may alternatively be sent by the server or compiled from source by the client using server- provided parameters. Additionally, or alternatively in another example, the server may include the one or more non-transitory computer readable storage media to store codes on the server. In yet another example, the one or more non-transitory computer readable storage media may be included in a part of a platform trusted by the server to store codes on the server. [0054] FIG.
  • the client-server system 210 may include a client 212 configured to execute a SALT generation function to provide a globally unique SALT value and combine the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password of a user; and a server 214 configured to receive the password hash from the client 212.
  • the server 214 and the client 212 may be in communication with each other, as denoted by a line 216.
  • the client may be associated with the user. For example, the client may be at the user’s end.
  • the client 212 may further be configured to generate the globally unique SALT value including a globally unique system identifier of the client- server system 210, and optionally a username of the user.
  • the globally unique SALT value may be the globally unique system identifier itself when only one password exists.
  • the username may be included in the generated globally unique SALT value when more than one account or more than one password exists in the client-server system 210.
  • the client 212 may further be configured to combine a globally unique system identifier of the client-server system 210 with a username of the user to generate the globally unique SALT value.
  • the client 212 may further be configured to perform at least one of: canonicalizing the username; or delimiting the globally unique system identifier; or delimiting the username. In other words, the canonicalization, or the delimitation, or both the canonicalization and the delimitation may be performed.
  • the client 212 may further be configured to encode the password hash by using at least one of: compile-time hash function parameters, single-instruction-multiple-data or prefetch instructions.
  • the client 212 may further be configured to cache the password hash.
  • the server 214 may further be configured to: receive, from the client 212, registration information provided by the user, the password hash, and optionally the user-provided password, wherein the registration information includes the username; optionally validate the registration information and optionally the user-provided password; and store, in a database accessible by the server 214, the password hash along with the username and optionally the registration information.
  • the database may be an external database.
  • the client-server system 210 may be configured to perform a registration process, e.g. as described for the method 100.
  • the server 214 may further be configured to: hash the password hash by using a hashing function to obtain a server-hashed password hash; and compare the server-hashed password hash and a validator placed in trust of the server 214 to obtain an indicator, wherein based on the indicator, the server 214 associates with the user to authenticate an identity of the user.
  • the hashing function may include a lightweight hashing function, or a keyed hashing function.
  • the client-server system 210 may be configured to perform a login process, e.g. as described for the method 100.
  • the client-server system 210 may further be configured to perform multi-factor authentication to provide an additional proof of the identity of the user, or a password authenticated key exchange to verify the password hash to mutually authenticate the client 212 and the server 214, or a hybrid exchange to authenticate the client by verifying the client’s knowledge of the user-provided password, and the server by using a way other than (or different from) the server’s knowledge of the user-provided password.
  • the client 212 may further be configured to combine the globally unique SALT value with the password hashing function to generate and provide a replacement password hash of a replacement user-provided password
  • the server 214 may further be configured to: additionally receive, from the client 212, the replacement password hash; optionally receive, from the client, the replacement user- provided password, or the user-provided password, or the username; and upon successfully authentication of the identity of the user, store, in a database accessible by the server 214, the replacement password hash in place of the password hash stored in the database, consequently performing a change of password, e.g. as described for the method 100.
  • the client-server system 210 may be configured to perform a method 100 for securely manipulating a password hash, in accordance with various embodiments.
  • FIG.3 shows a flow chart illustrating a method 320 for securing a user-provided password in a client for recovery only by an authentication server, according to various embodiments.
  • a password hash may be provided by the client (e.g.212 of FIG.2).
  • the password hash may be obtained from a method 100 (FIG.1) and stored in a database accessible by a server (e.g. 214 of FIG. 2), preferably during a registration process of the method 100.
  • the password hash may alternatively be obtained by using a lightweight hash of the user-provided password by the client, and in one example, such password hash may be salted, while in another example, such password hash may not be salted.
  • a public key and a private key may be generated and stored by the server.
  • the public key may be received from the server by the client.
  • the password hash may be encrypted based on (using) the public key by the client to obtain an encrypted password hash.
  • the encrypted password hash may be stored by the client in a storage medium, for example, a password manager or other storage media.
  • the encrypted password hash may be optionally associated with a username of a user and an identifier of the server.
  • the username may be the password hash or the username may be included in the encrypted data/encrypted password hash.
  • the username for the user to choose the right credentials is kept only if more than one username is stored on the same client.
  • the encrypted password hash and optionally the username may be received from the client by the server.
  • the client may be authenticated as the user by the authentication server.
  • the authentication server may be the server (214 of FIG. 2).
  • the step of authenticating the client 334 may include the encrypted password hash being decrypted using the stored private key 336; the decrypted password hash being optionally hashed using a hash function 338 (by the server); and determination 340 of the decrypted password hash or the optionally hashed decrypted password hash being the same as a value associated with the password hash previously stored in the database.
  • the determination step 340 may further include determination of the decrypted password being valid data.
  • the hashing function carried out by the server may include a lightweight hashing function, or a keyed hashing function.
  • the step of providing the password hash 321 may include obtaining, by the client, the username and the user-provided password 326; hashing, by the client, the user-provided password using the method 100 according to various embodiments to obtain the password hash 327; and storing the password hash in the database 341.
  • the steps 326, 327 and 341 may be performed during a registration process.
  • the method 320 is for binding stored credentials and more specifically, relates to a mechanism (Password to Token, “Pato”) by which a server provides a long-term public key that clients use to encrypt stored credentials. Such encrypted credentials can then be used instead of the password to authenticate the client.
  • Password to Token “Pato”
  • the random oracle model proves the security of the algorithm based on the method 320.
  • additional data is encrypted or at least authenticated on encryption
  • this may be used so that multiple clients, e.g. industrial internet of things (IIoT) sensors and actuators, interacting through a central server using the same password with the same server, may remain secure even if some of them are compromised.
  • communication may be assumed to happen over a secure channel on which the client has verified the server’s identity.
  • a possible example may be using transport layer security (TLS) and a certificate signed by a trusted certification authority.
  • client provisioning may be done as follows:- a. The server provides the client its long-term public key. b.
  • the client generates and encrypts (RSA style exchanges), or derives (Diffie-Hellman style exchanges), a random symmetric encryption key.
  • the client uses a secure symmetric authenticated encryption scheme, keyed using the random symmetric key from the prior step b., (e.g. a “Box” algorithm) to encrypt the credentials for storage (along with any additional data that may limit the usage of the key). If the server has not been given the password earlier, the client can now send its (encrypted) password to perform registration.
  • RSA style exchanges RSA style exchanges
  • derives Diffie-Hellman style exchanges
  • the client stores: the output of the “Box” algorithm that includes the result from the prior step; the encrypted symmetric key (RSA style exchanges) or, alternatively, the ephemeral public key (Diffie-Hellman style exchanges).
  • RSA style exchanges the encrypted symmetric key
  • ephemeral public key Diffie-Hellman style exchanges
  • a hash of the server’s public key may be stored by the client to ease the handling during key rollover.
  • any private key shares (or key material) generated by the client (Diffie- Hellman style exchanges) and all unencrypted symmetric keys (including plain password) are purged. Doing so ensures that only the owner of the server’s private key recovers the stored credentials.
  • Authentication of provisioned clients is done as follows:- i.
  • the client sends the encrypted credentials along with the additional data that was stored. Since the password ceases to be present on the client after provisioning, the password cannot be recovered from the information stored on the client, thereby being resistant to attacks performed by malwares, e.g. RedLine.
  • the server uses its private key and the “Box” algorithm to decrypt the credentials and additional data from the encrypted data sent by the client. iii. The server ensures that any additional constraints, asserted by the additional data that was decrypted, are met. iv. The server proceeds with authentication as usual using instead the decrypted credentials. [0070]
  • the “Box” algorithm described in more detail later on is an example for realizing the method 320. [0071] FIG.
  • a registration process may be provided.
  • the registration process 662 may include obtaining, by the client (e.g.212 of FIG.2), the user- provided password of a user and optionally a username of the user 664; and associating a value with the user-provided password 666.
  • a setup process may be provided.
  • the setup process may include generating and storing, by a server (e.g.214 of FIG.2), a public key and a corresponding private key 670.
  • a provisioning process may be provided.
  • the provisioning process 672 may include receiving, from the server by the client, the public key 674; encrypting, by the client, the user-provided password based on the public key to obtain an encrypted password value 676; and storing, by the client, the encrypted password value in a storage medium 678, e.g. a password manager or other storage media.
  • the encrypted password value may be associated with the username and an identifier of the server.
  • the stored encrypted value may be recovered by the client.
  • an authentication process to authenticate the client by the authentication server may be provided.
  • the authentication server may be the server (214 of FIG. 2).
  • the authentication process 680 may include retrieving, from the client and by the server, the stored encrypted password value 682; receiving, from the client by the server, the retrieved encrypted password value and optionally the username 684; decrypting the retrieved encrypted password value using the stored corresponding private key to obtain a decrypted value 686; and determining that the decrypted value is the same as the value associated with the user-provided password 688.
  • the provisioning process 672 may further include prior to the step 676 of encrypting the user-provided password, obtaining the user-provided password and optionally the username, by the client, if the user-provided password and optionally the username are not stored during the registration process 662; and associating the value with the user-provided password obtained during the provisioning process 672.
  • the step 666 of associating a value with the user-provided password during the registration process 662 may further include transforming, by the client, the user-provided password; receiving, from the client by the server, the transformed user-provided password; transforming, by the server, the transformed user-provided password to obtain a first transformed value; and storing, by the server, the first transformed value.
  • the step 676 of encrypting the user-provided password during the provisioning process 672 may include encrypting, by the client, the transformed user- provided password based on the public key to obtain the encrypted password value.
  • the authentication process 680 may further include transforming, by the client, the retrieved encrypted password value to obtain a transformed retrieved value; receiving, from the client by the server, the transformed retrieved value and optionally the username; and transforming, by the server, the transformed retrieved value to obtain a server-transformed value.
  • the step 686 of decrypting the retrieved encrypted password value during the authentication process 680 may include decrypting the server-transformed value using the stored corresponding private key to obtain the decrypted value.
  • the authentication process 680 may further include transforming, by the server, the decrypted value to obtain a second transformed value; retrieving, by the server, the stored first transformed value; transforming, by the server, the stored first transformed value to obtain a third transformed value.
  • the step of determining 688 during the authentication process 680 may include determining that the second transformed value is the same as the third transformed value.
  • the term “transforming” may mean performing a function with known input parameters one of which is the parameter to be transformed.
  • “transforming” may include “hashing” with or without a salt and with or without a key, functions such as addition, subtraction, or other mathematical or string operations, encryption, decryption, padding or unpadding.
  • the step of encrypting the transformed user-provided password during the provisioning process 672 may include transforming, by the client, the user-provided password to obtain a provisioning transformed user-provided password value; and encrypting, by the client, the provisioning transformed user-provided password value based on the public key to obtain the encrypted password value.
  • the provisioning transformed user-provided password value may be obtained based on a function or a set of functions that may be the same or may be different from those used during the registration process 662 to obtain the transformed user-provided password.
  • the function or set of functions for transforming or transformation performed during the registration process 662 may be the same as those used for the provisioning process 672 and/or the authentication process 680.
  • the function or set of functions for transforming or transformation performed during the registration process 662 may be different from those used for the provisioning process 672 and/or the authentication process 680.
  • the step of encrypting the transformed user-provided password or encrypting the provisioning transformed user-provided password value may include padding the transformed user-provided password or the provisioning transformed user-provided password value; and encrypting the padded transformed user-provided password or the padded provisioning transformed user-provided password value using public key encryption to obtain the encrypted value.
  • Decrypting the server-transformed value may further include unpadding the decrypted value.
  • the public key encryption may be any suitable public key encryption scheme.
  • hash function h and h' that may be salted or not and may be keyed or not, encryption function e(K+) and d(K-) and symmetric encryption function e(k) and d(k), where K+ may represent a public key, K- may represent a private key and k may be a key for symmetric encryption.
  • any chain of transformations described on method 660 can be evaluated for correctness by using the same technique of first recursively substituting the terms of the final comparison, then simplifying the application of an inverse function f ⁇ 1 to its corresponding function f, also taking into account that this simplification is possible when all of the functions applied between f ⁇ 1 and f are homomorphic regarding f and finally checking that the resulting simplified comparison contains the same sequence of functions applied on both sides and that said sequence only contains deterministic functions, that is, functions that given for all of the possible values of the input domain will always return the same output value from their image corresponding to said input value.
  • a chain of transformations can, for example, be built as follows: apply any set of transformations of the user-provided password by the client and the transformed user-provided password by the server during the registration process (662 of FIG.6); perform recursive substitution and simplification to the equation defining the resulting value (e.g.
  • the first transformed value ); apply a subset of the transformations from the resulting equation on the user-provided password by the client during the provisioning process 672; apply a set of transformations for which an inverse exists on the stored encrypted password value during the authentication process 680; apply the inverse transformations to those applied on the transformed stored encrypted password value to obtain a server-transformed value; further apply a subset of the transformations that where not applied when calculating value during the provisioning process so that only functions for which an inverse exists remain to be applied, on the second transformed value; applying the inverse functions to the first transformed value, on the third transformed value.
  • the resulting values of the comparison on the second transformed value and the third transformed value will be correct when tested as explained above.
  • the advantages of the client-side approach may include but is not limited to: having similar security to server-side approaches; having computational resources and energy consumption for the authentication process being smaller on the server (and on certain clients); having almost no computation on the server, where the effort is made by the client who tries to authenticate itself; lowering implementation costs; and securing storage of passwords on client side for faster and more energy efficient authentication on future iterations.
  • the client-side approach may be applied in a large array of “use cases” beyond plain registration, authentication, password change and password recovery.
  • implementation recommendations may include for: handling repeated password inputs; migration from server-side hashing databases; migration to improved client-side hashing databases; handling of multiple usernames associated with an account; caching of password hash computations; storage of password-hashes on the client with security properties equal to those of a token; and efficiently usage of credentials for non-human users.
  • client-side approach will be described in detail below.
  • A. Clipaha’s Design In order to ensure that strong password hashing solutions can be used in as many environments as possible, it is proposed for the computational load to be moved to the entity trying to authenticate itself (client) instead of the authenticator (server). With server relief, the client provides the brunt of the work to hash the password.
  • the following requirements may appear: providing the configuration parameters for the hash algorithm (thus, not requiring software developers to choose relevant security parameters); providing a unique salt value for the hash algorithm to ensure unique results; ensuring the user gets the correct salt value; preventing attacks from online and offline attackers (e.g. being resistant to salt collisions, user enumeration, and/or pass- the-hash attacks); ensuring the used password hash algorithm is as at least as secure as if it would be if performed by the server; and keeping the performance impact to legitimate users as low as possible.
  • the provision of the configuration parameters and the unique salt value may be typically done by the server once the user identifier is provided, such system may be open to a user enumeration attack, e.g. as online attackers can easily detect the lack of salt for unregistered users or see how they change over time.
  • a global set of parameters is proposed to be used and a hash value is derived by combining the user identifier (usually the username or e-mail address) with another string which uniquely identifies the whole user database. This string may be referred to as the database identifier.
  • this approach may introduce an additional issue in that if the same user has different usernames, the resulting salt and corresponding hash would change.
  • the username is canonicalized before use.
  • Canonicalization is the process of converting data that has more than one possible representation into a standard, normal or canonical form.
  • a choice must be made as to whether to publish the database identifier or not. If the database identifier is kept secret into the user database, then precomputation attacks may be noticed through log analysis because the attacker would still need to request the hash for each targeted username. In this case, as there would always be a valid value to return, even for users not in the database, the attacker does not gain any information about which user identifiers are present.
  • the database identifier may be made public, and the client may be provided with the canonicalization rules. By doing so, the whole operation may be performed directly on the client without any interaction from the authenticator until the client tries to authenticate itself.
  • Such an approach presents other advantages such as making it easier for a client to see if it can reuse cached credentials to avoid recalculation.
  • This design choice also ensures that the developer does not try to access the database, therefore, avoiding user enumeration attacks. Preventing user enumeration is a main argument to opt for this approach in Clipaha’s design.
  • Clipaha does not involve the server in the hashing process itself and instead, lets the client calculate the salt locally based on a deterministic database identifier (i.e., the server’s domain) and username. This choice deviates from the standard approach of using a random salt. It may be argued that only uniqueness, not randomness, is required to avoid salt collisions. Therefore, credential bruteforcing does not gain a significant structural advantage by having a predictable, low-entropy salt compared to the case where it has access to a random, high-entropy one. Clipaha’s design may include the same or like elements as those of the method 100 of FIG.
  • CANONICALIZEUSERNAME applies any transformations to obtain the canonical username (e.g., lowering the case to attain case-insensitive usernames). This ensures that the system returns the same hash for usernames that should be considered equivalent. To avoid user enumeration attacks, CANONICALIZEUSERNAME may operate offline and use only the username as input. Second, to further reduce the risk of salt collisions, DELIMIT ensures the canonical username and the database identifier do not mix together when their strings are concatenated. For example, the 32-bit little endian representation of the size of the input may be prepended to the input. Third, the hash of the password and the salt are computed and returned using a strong hash function PASSWORDHASH.
  • Argon2 may be chosen to satisfy the requirement of being at least as secure as if it would be if performed by the server.
  • Using Argon2 requires setting some input parameters, e.g. the size of the memory and time factors of the algorithm and the number of parallel threads to use. Instead of giving the developers full freedom of choice, only four hard-coded defaults: low, medium, high, and ultra are provided. These hardcoded defaults are named after the security level they provide (at the expense of performance and cross-compatibility).
  • Algorithm 2 describes the server-side hash.
  • CLIPAHASERVERHASH ( ⁇ ⁇ ⁇ ⁇ ⁇ h ⁇ ⁇ ⁇ h ) return HASH( ⁇ ⁇ ⁇ ⁇ ⁇ h ⁇ ⁇ ⁇ h) end function
  • the input to CLIPAHASERVERHASH would be the output of CLIPAHAHASH (of Algorithm 1). This function only performs a call to a one-way function HASH, which does not need to be computationally expensive. This prevents pass-the-hash attacks. Otherwise, an offline attacker (with read-only access to the database) can replay the entry in the database to access the service.
  • attackers also have as an objective to access the service without authorization.
  • two types of attacker models namely online and offline attackers, may be considered.
  • online attackers have access to the login system and try to use any available side-channel to learn information about the users on the system which they can make use of.
  • offline attackers have full access to the user database in one or more systems and try to gain as much additional information from their data as possible.
  • One such example would happen after breached user data is publicly exposed.
  • An online attacker may gain information not only directly from the responses but also by comparing responses over time or by using side-channels like, for example, timing differences.
  • client-side approaches have to face the same issues as server-side approaches: credential stuffing and user enumeration.
  • Credential stuffing (or interchangeably referred to as credential bruteforcing) involves an attacker trying credentials directly on the server to try to guess a valid pair. The effort for successful credential bruteforcing depends linearly on the computational cost of the hash function and exponentially on the entropy of the passwords.
  • User enumeration involves attempting to see if a user is registered on the system or not by directly querying the database or by detecting differences in responses.
  • Offline attackers also present similar challenges in both client and server-side approaches. After a breach, the attacker will try to crack the stored credentials prioritizing those that are more interesting. By allowing an attacker to make a guess on all the colliding credentials with a single hash operation, salt collisions put credentials at risk. Additionally, an attacker can see with little computational effort whether the same password was used on entries with colliding salts. On top of that, client-side approaches introduce the risk for pass-the-hash attacks. In a pass-the-hash attack, the attacker tries to use the already hashed credential stored in the breached database. Such an attack would work not only on the site itself but also on other sites with the same salt, password and hash parameters.
  • a salt value is added to passwords in order to increase an offline attacker’s effort when performing a dictionary attack against a large password collection.
  • two or more passwords are hashed using the same: salt, hash function, and hash parameters. Since an attacker may join all of the accounts sharing the same salt, only one hash operation may be needed to test a password guess against all of them simultaneously. Thus, the effort of the attacker would increase proportionally with the number of different salt values used by the targeted accounts. Similarly, an attacker can create rainbow tables to perform a time- memory trade-off for the attack if the number of different salts is small.
  • the implementation has to generate the salt in a way that ensures uniqueness both across users in a system and across different systems, especially when the username is similar.
  • this attack is only possible if there is a flaw in the random number generator (RNG) used by the client when registering a user. Otherwise, the possibility of an attack follows the same bounds of the known birthday problem which depends on the square root of the length of the salt. Therefore, in general, the system may be considered secure when using strong enough parameters.
  • RNG random number generator
  • this attack depends on how the salt is generated. If the username and the site’s domain name are concatenated, a collision may happen when these overlap across domains.
  • the salt would be the same as for alicee on mail.com: aliceemail.com.
  • this risk may be present for all usernames shared across different systems who have the same database identifier. For example, when different services are provided under the same domain name.
  • other instances of salt collision may arise as a result of using different approaches to concatenate the username and the database identifier, e.g. user abc.com on def.com which concatenates username first would share the salt with def.com on abc.com that instead concatenates database identifier first: abc.comdef.com.
  • Clipaha With respect to Clipaha, its generated salts are secure against such collisions when considering other systems using the same password and salt calculation method. Clipaha’s security stems from its salt components being unambiguously delimited. Since Clipaha uses a reasonably unique prefix that prefixes the unique database identifier with its size as a 32-bit integer, it is also unlikely that salts generated using other systems will collide.
  • B2.1 Proof of Salt Uniqueness [0111] Theorem B2.1.1. If the set of components is unique, a salt generated using an unambiguous mapping of such components is unique among all similarly generated salts. [0112] Proof of theorem B2.1.1.
  • Clipaha has an unambiguous mapping of generated bits to components.
  • Proof of theorem B2.1.2 The first four bytes delimit the global identifier length and are followed by exactly the represented number of bytes of a salt identifier allowing to unambiguously recover it from the result. Similarly, the four bytes after the global identifier represent the length of the username and are followed by exactly the length bytes of username. Consequently, recovery is unambiguous. Afterwards, there are no more bits left to map.
  • Per Lemma B2.1.1.1 C is known to be unique.
  • Per Theorem B2.1.2 the mapping of bits in S is known to be unambiguous. As the preconditions for Theorem B2.1.1 are satisfied, S is locally unique. Supposing the algorithm identifier is unique (and nobody else uses it), then per Corollary B2.1.1.2 is globally unique.
  • B3. User Enumeration Attacks [0119] In user enumeration, attackers check for the existence of users in the system by directly querying the targeted system or detecting differences in responses. First, to avoid user enumeration attacks, client-side approaches perform any extra server side steps even if the password is wrong to avoid timing side-channels.
  • Libsodium minimizes the impact of this attack by using Argon2 or Scrypt.
  • this attack is present for exactly the same reasons.
  • Crackstation recommends PBKDF2 which can be accelerated by a GPU an FPGA or an ASIC.
  • Such devices reduce the cost for the attacker and make precalculation more economically interesting. This incentive is exacerbated by the fact that such devices may also be used to calculate hashes used for credential stuffing.
  • Clipaha is also affected since the attacker can calculate the salt.
  • Clipaha uses Argon2id, that works as Argon2i (using data- independent memory accesses) for a first half of the first iteration over the memory and as Argon2d (using data-dependent memory accesses) for the rest, thus providing both protection against side-channel attacks and against brute-force cost savings due to time- memory trade-Off (TMTO).
  • TMTO time- memory trade-Off
  • Clipaha is compatible with password authenticated key exchanges (PAKEs), where a cryptographic key is negotiated using the password.
  • PAKEs password authenticated key exchanges
  • a password hash generated by Algorithm 1 being verified should be understood as "validated using the PAKE. All this in constant time, even if the user does not exist”.
  • the password hash generated by Algorithm 1 is inserted or updated on the database, this should be understood as "the password hash is provided as input to the algorithm that generates the server verifier. This verifier is then stored/updated on the database. All this is done in constant time whether the user exists or not”.
  • Clipaha is also compatible with Multi Factor Authentication (MFA). If MFAs are in place, their codes should be provided by the client before verification along with the plaintext password and validated during verification. If an action from the server, like sending an short message service (SMS), is required for MFA, it has to be performed after verification succeeds but before any further actions are carried. Additional server actions and MFA value validation should be in constant time and look the same even when the user has no MFA or does not exist to prevent side-channels.
  • MFA Multi Factor Authentication
  • the client e.g. 212 of FIG.2
  • the client is provided with the database identifier.
  • the user provides its username and password which are processed by Algorithm 1.
  • the client then sends the resulting hash and the username.
  • the server e.g.214 of FIG.2 proceeds to verify the hash against the database. If the username exists and the hash matches, the user is allowed in. Otherwise, a generic message similar to "Invalid username or password" is returned to be displayed. Additionally, care must be taken so that the verify operation takes the same amount of time if the user does not exist or the password is incorrect. [0133] User enumeration is avoided because all the data used is either global or directly provided by the user.
  • C2.2 Registration process [0134] During registration of a new user, the server (e.g.214 of FIG.2) sends the database identifier to the client (e.g. 212 of FIG. 2). Optionally, the client verifies the password policy details that are user independent and not confidential (e.g. length or complexity) showing an error if the test fails. The client then sends the registration details and the password both in plain text and hashed using Algorithm 1. The server then validates all fields, including that the plaintext password matches the full password policy. If the verification fails the server returns an error to the client.
  • the server e.g.214 of FIG.2
  • the client verifies the password policy details that are user independent and not confidential (e.g. length or complexity) showing an error if the test fails.
  • the client sends the registration details and the password both in plain text and hashed using Algorithm 1.
  • the server validates all fields, including that the plaintext password matches the full password policy. If the verification fails the server returns an error to the client.
  • the server inserts the password hash along with the new user in the database (and proceeds with any further steps, like e-mail verification).
  • the existing user is notified through an alternative communication way, but without showing a different error message to the user carrying out the registration. Timing of the insertion and any operations afterwards must be the same whether the user is present or not.
  • the client can be trusted to send the hashed password matching the sent plaintext password. If these were different, the client may bypass the password policy verification by sending instead a policy-breaking hashed password.
  • the risk of this issue may be deemed low. Despite that, this may be addressed by either computing the hash on the server or, alternatively, by delegating this computation to a trusted and more powerful server.
  • One of the security issues that may arise is that the client sends a plaintext password different from that on the hash.
  • the server may perform the hash and policy verification by itself. This may open the server to a DoS attack. Consequently, the risk of this issue may be deemed low since bypassing password policies would be against the user’s interests and, even if done, the impact may be limited to the user’s account. Therefore, client-side verification may be preferred.
  • C2.3 Password change process To change passwords, the server (e.g.214 of FIG.2) sends the database identifier and the current session’s username. The client (e.g. 212 of FIG.2) then asks for the new password and hashes this new password using Algorithm 1. The client may optionally ask for the original password and if needed to prove its identity, hashes this original password using Algorithm 1 as well, thus taking twice as long. The client then sends the hash(es) and optionally the password(s) to the server.
  • the client verifies the password policy details that are user independent and not confidential (e.g. length or complexity) showing an error if the test fails.
  • the server may proceed to verify that the old password hash matches the one of the current user. If it does not, it returns an error message to the client. Otherwise, it may optionally check that the new password plaintext complies with the password policy. If similarity to the old password has to be verified, this can optionally be done using the client provided plaintexts. If all goes through correctly, the server updates the database using the new password. [0137]
  • the password change process presents the same challenges and complexities as registration regarding password policy verification.
  • a CSRF attack may allow an attacker to change the password to take over an account when the old password is not requested and verified (unlike what may be recommended).
  • appropriate measures like sending the original password hash or optionally using a CSRF token if the original password hash is not sent, have to be taken. Because this process depends on an authenticated session already being in place and only affects the user itself, other security issues are not a direct concern.
  • C2.4 Account recovery process [0138] Account recovery works almost in the same way as password change.
  • the client e.g.212 of FIG.2
  • the client also sends the username, the hash, using Algorithm 1, of the new password, and optionally the plaintext of the new password.
  • the client verifies the password policy details that are user independent and not confidential (e.g. length or complexity) showing an error if the test fails.
  • the server e.g. 214 of FIG. 2 verifies in constant time the correctness of the token and that it belongs to the username, and also verifies the password matches policy. If any check fails, the server returns a message indicating the corresponding invalidity. If all went through, the server updates the user’s password entry on the database.
  • the security concerns are the same as for password change with two exceptions. First, CSRF is not a concern because token validation is mandatory; and second, recovery tokens must be random and unpredictable enough so that an attacker cannot guess them. Generating at least 256-bits of random data may be secure enough.
  • the login process remains the same on the client-side, where the client (e.g. 212 of FIG. 2) sends both the hashed and unhashed passwords to the server (e.g.214 of FIG.2).
  • the server performs a hashing round with the legacy algorithm using the plaintext password (even if the user is already migrated or not present) and then verifies in constant time if this hash matches the one corresponding to the user.
  • the server verifies the client provided hash too (even if the user was not migrated or present). If the verification matching the current user status fails or the user is not present, the message for an invalid username or password is presented and the process stops. Otherwise, the server updates the user’s entry using the client provided hash and marks the account as migrated.
  • the client e.g.212 of FIG.2
  • the server e.g. 214 of FIG. 2
  • the server increases the failed login counter, stores the used password hash on the client’s session and tells the client to retry.
  • the client uses the old hash algorithm and sends both hashes to the server.
  • the server checks that the session has a stored hash from the prior steps and ensures it matches in constant time (failing when it does not).
  • the server verifies that the old hash matches the one in the database. If verification fails, or the user is not present, or is already migrated, the server fails with the usual invalid username or password message and deletes the hash stored on the session. Otherwise, authentication succeeds and the server updates the user account using the password hash made with the new algorithm. [0147] This approach avoids user enumeration by avoiding giving information to the client on which specific algorithm to use based on the username and by ensuring that, if the password is wrong, the attacker does not fully know so until the old password hash is also verified.
  • This algorithm prevents two-by-one attacks by ensuring that the client only gets one try with the old hash after it has done a try using the new hash (by storing it in the session, validating it on the next step too, and deleting it when the old hash verification fails). This session information must be kept on the server side to avoid replay attacks. Otherwise, all the security assumptions applying to old database migration apply also here.
  • C3.3 Multiple hard to canonicalize usernames [0148] Some systems (e.g. 210 of FIG. 2) use more than one independent user identifier for the same user.
  • One such example are social networks like Twitter where a user can be identified by username, phone number or e-mail address. To address such a requirement, the password handling processes may be modified.
  • the first step is having a password hash on the database for each independent user identifier. Hash verification only compares with the one belonging to the provided username. Registration requires the user providing the hashes for each of the identifiers.
  • the server e.g. 214 of FIG. 2 provides a username list instead of a single username and the client (e.g. 212 of FIG. 2) provides a new password hash for each of the provided usernames (and an old password hash for one of them).
  • Account recovery with client-side hashing works on a similar way by providing the list of identifiers to hash the new password with when the one-time token is valid for the provided username.
  • the client keeps the plaintext password until login is finished.
  • the server If the account is not migrated yet and login succeeded, the server provides a list of user identifiers for which new hashes have to be derived by the client. The client then sends back the results for the server to store.
  • migration can proceed normally without providing any identifier list and the administrators disabling any non-migrated user identifiers after some time has passed.
  • user enumerations are mainly avoided by providing the full username list only when the client has successfully authenticated before. Similarly, to avoid birthday attacks, verification is only made against the one verifier belonging to the provided username. Otherwise, the same assumptions as for their original processes apply to the modified ones. C4.
  • Client-side Only Scenarios C4.1 Client-side caching of password hashes [0151] Since the computation result is deterministic, client-side applications may cache the hash computation for later retrieval to save resources. [0152] To avoid credential stuffing, when this caching is done across different applications or domains, the cache ensures it takes the same time to provide the hash as it took to calculate it and that requests are not processed simultaneously. Doing so, prevents timing side-channels which allow guessing if some other application or domain has tried a specific combination of algorithm, database identifier, username and password. Similarly, the keys and the contents of the cache may be used to impersonate users. To reduce the risk of credential stealing, the cache also ensures data is never stored on long term storage without proper encryption.
  • the cache keeps data only in non-swappable RAM.
  • caches also clear stored entries after some time without use has passed and limit the amount of entries a domain or application can use.
  • C4.2 Password managers [0153] Password managers can interact with the client-side code using Clipaha and provide (along with the plaintext password) the already hashed password and the parameters used. The client (e.g. 212 of FIG. 2) can then use this hash to avoid performing its own calculation. Similarly, the client-side code can send new hashes (along with the input parameters) to the manager for later retrieval.
  • the manager stores the hashed passwords using the same security measures used for the plaintext. Similarly, the manager also uses the same access policies it would use for the plaintext password.
  • C4.3 Non-human authentication Services may need to be available to embedded devices that try to authenticate themselves. Assuming that accounts are not shared, such devices may use instead a random token calculated and registered during provisioning. The random token needs to be sufficiently long, preferably being the same length as the client-side hash, e.g. 256 bits. The token may replace the client-side hashed password during verification.
  • the Clipaha library is aimed at being compatible with various devices. To use the library, an exemplary Clipaha’s API may be as in Listing 1 below.
  • Listing 1 Clipaha’s API example function handle_success (epassword) ⁇ //Make use of the encrypted password here ⁇ function handle_error (details) ⁇ //Handle error appropriately ⁇ //Replace VERSION with low, med, high or ultra Clipaha_VERSION_hash (domain, username, password, handle_success, handle_error) [0158] To avoid confusion, the database identifier has been named domain (as that is usually its content and is a reasonably safe default). The only other required parameters are the user identifier (called username for similar reasons), the password, and the success and error callbacks. The hash covers Algorithm 1 except the canonicalization (to avoid complex APIs).
  • This API also purposefully hides the hash parameters. Doing so may avoid some of the usability issues, and make coding a user enumeration scenario more diffcult while ensuring that the code is better optimized by the compiler.
  • D1. Proposed Security Levels [0159] Since Clipaha moves the resource usage to the client devices, developers may want to ensure that their applications are run on a large array of devices. To allow balancing security and compatibility, the library provides four security-levels with the library: low, medium, high and ultra. The specific parameters used when hashing the password with Argon2id are provided in Table 2, where iterations refer to the number of rounds the algorithm runs, and memory is the amount of memory used by the hash function.
  • the security level low is intended to maximize support of very old devices, e.g. some ancient smartphones, ebook readers or even computers from the early 2000s. medium targets all computers from the mid 2000s and most smartphones and ebook readers from the last 5 years. high is the value that is recommended for new developments where only computers from the last 5 years are considered.
  • ultra uses the maximum amount of RAM possible on our current implementation (a bit less than 2GiB because of limitations on Emscripten, the SDK used) and runs flawlessly on most modern laptops with at least 3GiB of RAM.
  • the parameters used when hashing the password with Argon2id in the current implementation of clipaha.js are chosen to fit the memory of the device class and use as many/few iterations to keep the execution time below 20 seconds. Since higher memory requirements also involve more computation per iteration, the number of iterations needed in lower security levels is higher. [0162] Introducing security levels may represent a potential security threat. An attacker preferably targets systems using the low security level, which has lower requirements on computation and memory. Therefore, allowing a powerful offline attacker to execute credential bruteforcing at a higher rate.
  • statically allocated buffer allows for disabling malloc and reduces the risk of an allocation failure caused by fragmentation. But as such issues are not observed on real systems and the only malloc allocation done is the huge buffer used by Argon2, it may be preferable to opt not to provide the statically allocated buffer.
  • some browsers disabled the possibility of using shared memory buffers across web workers to avoid allowing their usage as a timer for exploiting side-channel attacks. In this area, the situation has improved with some browsers allowing their usage under certain specific conditions.
  • Lyra2 BlaMka hash function, the core of Argon2, makes heavy use of 64-bit multiplication, addition, rotation and bitwise operations.
  • WebAssembly increases the performance by providing 64-bit integer support and compilation into native code and yet, presents certain performance limitations over native code.
  • SIMD single instruction, multiple data
  • preliminary testing hints that, despite still being rolled out, support for 128-bit vector SIMD provides a runtime improvement of around 20%.
  • the WebAssembly penalty may be caused by optimization choices when compiling the middle code and by the lack of native SIMD support for the full vector length along with some minor overheads.
  • the JavaScript one is clearly consistent with the expected impact from using an interpreted language.
  • JavaScript does not provide any guarantees regarding the lifetime of variables. That, mixed with the fact that strings are immutable objects, means that any approach to control the time of life of the password on the heap may be fruitless. Consequently, it is not opted for inputs or hash memory to be sanitized since doing so does not provide a significant improvement in security.
  • E. Evaluation [0172] A test to evaluate the deployability of Clipaha was performed.
  • the first uses an additional locally executed hash function, in this case SHA256, for additional security to avoid pass-the-hash attacks.
  • the second performs a raw string comparison with a locally stored password.1000 measurements of the time it took to hash and securely compare the encrypted password on the device along with the time it took to process a login request with the local hash and make a raw comparison were performed.
  • the hash measured for 3.7% of the time it took to perform the request with a median of 735.425 ⁇ s for the hash and 19604.25 ⁇ s for the full requests. Requests without the hash had a median of 19005.1 ⁇ s in comparison.
  • the code on the server side is fast even when run on a microcontroller (e.g. less than 20 ms).
  • Benchmarks [0175] The benchmarks are compared against a similar implementation using lisodium.js (that hashes the salt using Blake2 before further encryption to ensure the 16-byte fixed-size requirement of the library is met). The benchmark was successfully tested on 21 different devices and 35 setups. The benchmark was also tested on 7 devices and setups that crashed before finishing the test. [0176] A summary of the benchmarking results are shown in Table 4, where the number of failures (F), minimum (Min) and maximum (Max) seconds taken to run are presented for each security level, device type and library. Only devices with at least a success are considered. Each security level was tested 5 times per device and browser.
  • Table 4 Library low medium high ultra Device F Max Min F Max Min F Max Min type 8 4 4 7 0 p . p or each system browser and library, with the median hashing time in seconds out of 5 encryptions, each with a different username and password, were compiled. Some examples are shown in Table 5.
  • Clipaha’s approach improves by at least 50% the runtime of existing approaches and demonstrates that it can run in a resource constrained device. It is speculated that this may be caused either by additional overhead in libsodium.js or by the fact that Clipaha uses fixed Argon2 parameters which may allow the compiler to produce faster code.
  • the data also shows that phones are up to ten times slower than computers. Such a difference may be caused by slower memory in phones, a slower processor, or worse optimization of code by the phone-based browsers.
  • Clipaha completed the benchmarks in certain devices on which libsodium failed. This may be caused by the early allocation of memory made by Clipaha which helps avoid fragmentation.
  • Clipaha With its user friendly API and code, Clipaha has the potential to impact embedded systems, e.g. small office home office (SoHo) network appliances and IoT gateways that are resource constrained and rarely require flows more complex than registration (during provisioning) and authentication.
  • SoHo small office home office
  • IoT gateways that are resource constrained and rarely require flows more complex than registration (during provisioning) and authentication.
  • password-based credentials that include the password with a key known only to a specific server
  • a password may be converted into a token: a piece of high entropy data that can be used for authentication but which says nothing about the password of the user it authenticates. Tokens are different from passwords in that tokens are automatically generated and are difficult for humans to remember.
  • the mechanism is based on public key cryptography for protecting passwords stored on client devices so that an attacker, compromising only the client, cannot gain any information about the stored passwords.
  • the attacker gains nothing from obtaining only the server’s private key as the attacker would also need the client’s token to be able to obtain the credentials and attack others. Ways may be introduced to model indistinguishability from random noise when the attacker has a dictionary containing the correct plaintext, and the model proves the security of the mechanism.
  • tokens are usually implemented in one of two ways: as a shared secret (also called API key) or as a cryptographically signed authenticator. For shared secrets, the client obtains and stores a random string from the server which is then presented instead of the password for authentication.
  • TPM Trusted Platform Module
  • TEE trusted execution environment
  • PUF physically unclonable function
  • MFA approaches try to combine various techniques to gain their strengths and reduce the impact of exploitation. MFA approaches do not improve the protection of the stored passwords otherwise and do not prevent an attacker from performing offline attacks against stored passwords. Consequently, if an attacker can guess the password for another server which is not, or can not be, protected using MFA, this server may still be attacked successfully. These techniques introduce additional requirements on the user that require significantly more than just remembering the low entropy pair of username and password. This is true even for MFA. [0192] In other words, a mechanism based on public key crypography is proposed for protecting passwords stored on client devices so that an attacker compromising only the client cannot gain any information about the stored passwords. For example, extensions may be introduced to perform key rolling, client-side hashing and additional binding data.
  • the "Box” algorithm has to encrypt the password providing the following three security properties.
  • Decryption correctness The server can recover the encrypted data using its private key.
  • Authenticated encryption Relevant adversaries, which are computationally bound to ⁇ and tamper the encrypted data they send, can have it accepted by the server with negligible probability. [0199] A padding step may be added to ensure length obfuscation. The data is padded before encryption, consequently, the resulting construction provides indistinguishability with variable lengths. [0200] Since the client’s private key is destroyed immediately after the password is encrypted, the adversary only has knowledge of the public keys of both sides and, therefore, is unable to guess the resulting shared key. [0201] The mechanism performs credential encryption during storage on the client-side instead of the server side.
  • this step may be offloaded to the server in a way similar to key rolling, that will be described later on, thus avoiding any public key cryptography on the client-side.
  • Offloading the initial encryption requires sending the plaintext password to the server over the secure channel at least once. Although this would be a valid approach if the channel was truly secure, instead, it may be preferred to ensure that the password is always sent encrypted to the server. This simplifies the protocol slightly and makes the proof more simple but, more importantly, this ensures the security of this protocol stacks on top of that of the secure channel against passive eavesdroppers following an ‘intercept now, decrypt later’ approach.
  • a different approach to ensure length obfuscation instead of adding padding to the password before encryption is applying a hash function to it. This approach may be described in similar context to the method 320 of FIG.3. Since the objective is extracting the password’s entropy into a fixed-size string, the hash can be any cryptographic hash function that is still secure.
  • the server When prehashing the password, the server will only be able to recover the password hash instead of the original password, hence the authentication process needs to be modified to work over the hashed password instead of the plaintext password. For example, the server’s verifiers must be generated over the already hashed password. Hashing the password securely on the client-side requires changes on the authentication procedure. Consequently, although this may be a useful extension, the padding approach may be chosen to be used by default for encryption so that the length of any additional data can be hidden. [0205] It is also possible to include certain additional data along with the password in order to limit usage of the encrypted password.
  • a password may include one or more of: targeted service(s) or server(s); clients that are allowed to use the password; actions allowed or access level granted.
  • Adding this data raises the security by explicitly limiting the scope in which passwords stored in a client may be used and by explicitly stating the targeted server, as opposed to doing so implicitly by the specific public key being used for encryption. Implementations also require additional code for validating this data when performing the password recovery step on the server or, if no validation is desired, to remove it so that only the password is provided to the authentication system.
  • the risk of the data being modified by an attacker ought to be considered. Such risk is prevented by ensuring that the encryption cipher used in the box construct is an authenticated encryption scheme, e.g.
  • the server may need to change to a new public key pair, e.g. after the old private key is compromised. Key rolling may be required.
  • the server always keeps a copy of old private keys to be able to decrypt credentials encrypted using these.
  • the server since the server gains access to the plaintext credentials once the client authenticates, the server also performs the same encryption steps the client would perform when storing credentials using the new public key, and sends these new encrypted credentials back to the client for storage. Further, to prevent DoS attacks, the client keeps the old ones available until it verifies the new credentials work (and maybe for a short additional period).
  • the server may attempt to use both of the private keys while blinding the computation to avoid side-channels if the first decryption succeeds. Failure to do so may allow an attacker to obtain information about the username’s presence in the database.
  • an attacker As a consequence of the use of public key cryptography to bind the credentials to a specific server, without the corresponding private key that the server uses to decrypt the encrypted credentials, an attacker with full access to the client data cannot obtain the credentials that were originally encrypted. Such an attacker can still use the client’s data to impersonate the client against the specific server. To avoid this, techniques e.g. MFA multifactor authentication may be additionally used.
  • a real game provides the attacker with the stored password and any auxiliary data the client uses to process it, including any data that the server provides to the client.
  • An ideal game provides the attacker with random pieces of data of the same length instead.
  • the oracle Given an integer value ⁇ ⁇ 1 and a password p when first instantiated, the oracle generates a set composed of the correct plaintext password p along with other ⁇ ⁇ 1 random strings, and the oracle creates a list formed from a random permutation of all the elements in the set. The resulting oracle then answers the i-th query by the adversary, returning the i-th item xi from the list. Alternatively, when the last item of the list has already been provided, the oracle returns ⁇ .
  • IND- CPA The game used for IND- CPA as defined in Listing 3 as follows: IND ⁇ CPA ⁇ (1 ⁇ , ⁇ ) IND ⁇ CPAL ⁇ (1 ⁇ , ⁇ ) 5: ⁇ ⁇ $ BOXENCRYPT( ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ) 5: ⁇ ⁇ $ BOXENCRYPT( ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ) 6: ⁇ (1 ⁇ , ⁇ ⁇ ⁇ ⁇ , ⁇ , ⁇ , ⁇ ⁇ ⁇ ⁇ ) 6: ⁇ (1 ⁇ , ⁇ ⁇ ⁇ ⁇ , ⁇ , ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ )
  • the IND-CPA is side-by-side with the IND-CPAL (indistinguishability under chosen plaintext attack with variable length) in Listing 3 above.
  • the adversary’s guess of the value of b
  • ⁇ ⁇ ⁇ ⁇ ⁇ 2
  • a protocol is considered to be secure ⁇ ⁇ ( ⁇ ) .
  • the algorithms may be modified to match two requirements: first, it must always return an encrypted message of the same length independently of the length of its input; and, second, the original indistinguishability property must still hold. [0230] To ensure the encrypted message has the same length, it can be benefitted from the fact that both games do guarantee the same output length for all inputs with the same length. Hence, all the possible inputs need to ensured to be mapped into a set of strings of a fixed length and this process is called length obfuscation.
  • a traditional approach to perform length obfuscation would be defining a maximum allowed message length (i.e., how long can the password p be at most) and then pad the input strings before processing them so that all of the possibles messages up to said length have exactly the same final length.
  • M ⁇ 1 ⁇ 0,1 ⁇ (0,..., ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ h)
  • a pad function is defined as that for ⁇ ⁇ ⁇
  • ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ : ⁇ ⁇ ⁇ M ⁇ 1 : ⁇ ⁇ ⁇ ⁇ ( ⁇ ⁇ ⁇ ( ⁇ )) ⁇ , i.e.
  • this may be done using a strong password hash. This can also ensure that the resulting string has always the same length without needing to limit the input size. Additionally, doing so may be more efficient since it reduces the workload the server has to perform during authentication.
  • IND-CPA plaintext attack
  • O is the oracle described above
  • u is the ⁇ ⁇ is the encrypted password
  • ⁇ ⁇ ⁇ ⁇ ⁇ is the server’s long term public key
  • ⁇ ⁇ ⁇ ⁇ ⁇ is the client’s temporary public key for the Diffie-Hellman exchange.
  • BOXENCRYPT ( ⁇ ) returns ( ⁇ ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ ) while purging the private key ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ and shared key ⁇ h ⁇ which are therefore not available to the adversary.
  • ⁇ 1 is defined as winning if it can return p with significant probability when ( ⁇ ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ ) ⁇ $ BOXENCRYPT ( ⁇ ) and ⁇ otherwise.
  • various examples and embodiments of the invention may include the following: • A server-assisted approach may be provided to convert passwords into authentication tokens from which no password information can be derived. This tokenization happens in a way that makes using already existing infrastructure possible (the client just performs the encryption on storage while the server performs one decryption before proceeding with the usual password authentication). Additionally, knowledge of the password still suffices to authenticate. • The usefulness of the random oracle model may be introduced to prove the security of stored credentials after a compromise and a way to model off-line dictionary attacks. Then, this model may be used to provide a mathematical proof of the security of Pato.
  • Pato may be expanded allowing the addition of additional data to the generated tokens to be able to restrict their usage; and allowing rolling over keys after a compromise of the server’s private key.
  • PAKEs Password Authenticated Key Exchanges
  • Blinding approaches like those described herein may be combined with the existing (usually public key based) server-authenticating secure channel provided by the server-side to develop a hybrid key exchange approach that ensures client compromises will not disclose passwords.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

According to embodiments of the present invention, a method for securely manipulating a password hash is provided. The method includes executing, by a client associated with a user, a SALT generation function to provide a globally unique SALT value to the user, wherein the client is part of a client-server system; and combining, by the client, the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password. In one embodiment, the step of executing the SALT generation function may include combining a globally unique system identifier of the client-server system with a username of the user to generate the globally unique SALT value. According to further embodiments, a client-server system involving secure manipulation of a password hash and methods for securing a user-provided password in a client for recovery only by an authentication server are also provided.

Description

METHOD FOR SECURELY MANIPULATING A PASSWORD HASH, A CLIENT- SERVER SYSTEM INVOLVING THE SAME, AND METHODS FOR SECURING A USER-PROVIDED PASSWORD IN A CLIENT FOR RECOVERY ONLY BY AN AUTHENTICATION SERVER Reference To Related Application [0001] This application claims the benefit of priority of Singapore patent application No.10202251389F, filed 14 October 2022, the content of it being hereby incorporated by reference in its entirety for all purposes. Technical Field [0002] Various embodiments relate to a method for securely manipulating a password hash and a client-server system involving secure manipulation of a password hash. Other embodiments also relate to methods for securing a user-provided password in a client for recovery only by an authentication server. Background [0003] Password-based authentication remains one of the most prevalent authentication mechanisms. It is understandable why passwords are still popular as they require no extra hardware for the user(s). They are also easily carried by the user(s) across systems and can be shared among users if needed. Implementation of passwords is quite straightforward. [0004] Despite such advantages, passwords have some shortcomings. After compromising a device, e.g. after leaking a password database or after exfiltration of stored hashed credentials and performing dictionary attacks to find original passwords, issues such as password reuse allow attackers to use extracted credentials to compromise affected users’ accounts on other services. Such reuse of exfiltrated credentials or exfiltrated hashed credentials can allow the attacker(s) to impersonate other devices and servers across a network. This is problematic on Industrial Internet of Things (IIoT) networks that frequently use a single low entropy password shared across devices. The impact of exfiltrated passwords enabling further exploitation on a network further raises a challenge on protecting stored passwords after a compromise, from e.g. dictionary attacks, while ensuring that knowledge of the password still suffices for authentication purposes. This challenge cannot be resolved by the server side because the server needs to authenticate the client and, for password-based authentication, cannot expect the client to keep additional data to protect the verifiers stored by the server. Basically, password security relies heavily on the choice of password by the user. [0005] To slow down attackers, passwords can be stored after using a one-way hash. Password hashing is a security measure that converts passwords into illegible strings of characters, known as hash. A common way to secure such hashes is by using computationally expensive hash function(s) that has been made more complex in terms of computational power and memory requirements to compensate for the increased computing power of attackers. However, an attacker can still perform unlimited password guesses in parallel once these hashes are leaked out. After a successful compromise, attackers may recover stored password hashes. These hashes may then be cracked and used on other services where the same or similar passwords may have been reused. [0006] Techniques like salted hashes ensure that an attacker needs to attack each user’s password individually. A salt is a piece of text added (usually prepended) to a password before hashing. Salts can be public and create unique password hashes even if two users choose the same password. When verifying the password, the salt is fetched or reconstructed, prepended to the password, hashed using the same algorithm and then compared against the stored entry. Salted hashes increase the search space linearly with the number of users. However, attackers can make use of devices, such as graphics processing units (GPUs), field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), that can perform a huge number of guesses per second and per watt. By making significant use of processing power, memory space and memory bandwidth, some techniques involving salted hashes make such devices either perform similarly to central processing units (CPUs) or become unable to run the algorithm. [0007] Hashing is usually done on the server, consuming large amount of resources that need to be available during each authentication attempt. Consequently, authentication cannot be performed on embedded devices lacking such resources. These resources put servers under significant strain that may even allow denial of service (DoS) attacks. Such attacks can be performed simply by sending a large number of authentication requests, thereby exhausting either the CPU time or the available memory. In other words, computing the hash function(s) at every login attempt exposes servers to DoS attacks and the range of devices that can provide a high level of password security is also limited. [0008] Using modern password hashing algorithms such as Argon2 may compensate for possible attacker advantage from accelerators. However, its large cost parameters already may have a large impact on normal servers, e.g. allocating one gigabyte of RAM per login attempt for a few seconds may open such a system to a DoS attack or, if it scales automatically, make it easy for an attacker to multiply the costs of operation. If the increasing number of IoT scenarios are to be considered where resource constrained devices cannot cope with the resources required by secure password hashing algorithms, the need for a different approach becomes clearer. Argon2 has had some further improvements and refinements leading to e.g. the creation of Argon2id that mixes a data independent iteration with data dependent ones to avoid both timing side-channel attacks and time-memory trade-off attacks. [0009] Thus, there is a need for a method and system to delegate the computation, e.g. to the entity being authenticated (e.g. the client), to address at least the problems mentioned above, and to enable server relief, while providing strong security parameters on regular systems and even more so, on resource-constrained systems. [0010] While client-side password hashing may be covered by e.g. Libsodium’s approach and Crackstation’s approach, these existing works only touch this topic tangentially. There are also no existing techniques for storing credentials on a client so that only the desired server can recover the stored credentials. [0011] In the client-side, unless the client has to mutually authenticate the server’s knowledge of the password, full protection against attackers having full control of the client may be possible. Current approaches to protect such credentials, e.g. passwords stored on the client, involve, e.g. symmetric encryption, storage of a hash of the password and share partitioning. Symmetric encryption may be by using a password manager, some feature of the operating system, a TEE or a TPM device, more esoteric approaches e.g. Client-CASH, or a combination of them; or has a point of failure in that the password needs to be provided to the legitimate program for further use. Therefore, in such systems, an attacker can just interfere with or impersonate the legitimate software to be able to get access to the credentials once decrypted. On the other hand, storing a hashed version of the password on the client prevents the attacker from directly obtaining the plain text credentials as hashes are one-way functions. Despite that, the attacker may still be able to perform an offline dictionary attack to try to obtain the encrypted password. Share partitioning is an approach in which a group of servers are used to protect a password from dictionary attacks without any of the servers knowing the password. Share partitioning presents some shortcomings in that to be useful, it requires various servers simultaneously while a single server failure would break the protocol. It focuses on users changing terminals instead of on multiple client devices sharing a password, and also does not provide a mathematical or formal proof of its security. Summary [0012] According to an embodiment, a method for securely manipulating a password hash is provided. The method may include executing, by a client associated with a user, a SALT generation function to provide a globally unique SALT value, wherein the client is part of a client-server system; and combining, by the client, the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password of the user. [0013] According to an embodiment, one or more non-transitory computer readable storage media are provided. Each of the one or more non-transitory computer readable storage media may have stored thereon at least part of a processor-executable software instruction set, wherein the processor-executable software instruction set is configured to cause one or more processors to execute a method for securely manipulating a password hash, according to an embodiment. [0014] According to an embodiment, a client-server system is provided. The client-server system may include a client configured to execute a SALT generation function to provide a globally unique SALT value and combine the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password of a user, wherein the client is associated with the user; and a server configured to receive the password hash from the client. [0015] According to an embodiment, a method for securing a user-provided password in a client for recovery only by an authentication server is provided. The method may include providing, by the client, a password hash obtained from a method according to an embodiment or by using a lightweight hash of the user-provided password; generating and storing, by a server, a public key and a private key; receiving, from the server by the client, the public key; encrypting, by the client, the password hash based on the public key to obtain an encrypted password hash; storing, by the client, the encrypted password hash in a storage medium; receiving, from the client by the server, the encrypted password hash and optionally the username; and authenticating the client as the user by the authentication server. The encrypted password hash may be optionally associated with a username of a user and an identifier of the server. The step of authenticating the client may include decrypting the encrypted password hash using the stored private key; optionally hashing the decrypted password hash using a hashing function; and determining that the decrypted password hash or the optionally hashed decrypted password hash is the same as a value associated with the password hash previously stored in a database accessible by the server. [0016] According to an embodiment, a method for securing a user-provided password in a client for recovery only by an authentication server is provided. The method may include providing a registration process, providing a setup process, providing a provisioning process, and providing an authentication process. The registration process may include obtaining, by the client, the user-provided password of a user and optionally a username of the user; and associating a value with the user-provided password. The setup process may include generating and storing, by a server, a public key and a corresponding private key. The provisioning process may include receiving, from the server by the client, the public key; encrypting, by the client, the user-provided password based on the public key to obtain an encrypted password value; storing, by the client, the encrypted password value in a storage medium. The encrypted value may be associated with the username and an identifier of the server. The authentication process may include retrieving, from the client, the stored encrypted password value; receiving, from the client by the server, the retrieved encrypted password value and optionally the username; decrypting the retrieved encrypted password value using the stored corresponding private key to obtain a decrypted value; and determining that the decrypted value is the same as the value associated with the user- provided password. Brief Description of the Drawings [0017] In the drawings, like reference characters generally refer to like parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments of the invention are described with reference to the following drawings, in which: [0018] FIG. 1 shows a flow chart illustrating a method for securely manipulating a password hash, according to various embodiments. [0019] FIG.2 shows a schematic representative view of a client-server system involving secure manipulation of a password hash, according to various embodiments. [0020] FIG. 3 shows a flow chart illustrating a method for securing a user-provided password in a client for recovery only by an authentication server, according to various embodiments. [0021] FIG.4 shows a schematic representation of the concept of Clipaha, according to an embodiment. [0022] FIG.5 shows a schematic representation of an existing server-side hashing (prior art), according to an example. [0023] FIG. 6 shows a flow chart illustrating a method for securing a user-provided password in a client for recovery only by an authentication server, according to other embodiments. Detailed Description [0024] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be utilized and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various embodiments are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. [0025] Embodiments described in the context of one of the methods or devices are analogously valid for the other methods or devices. Similarly, embodiments described in the context of a method are analogously valid for a device, and vice versa. [0026] Features that are described in the context of an embodiment may correspondingly be applicable to the same or similar features in the other embodiments. Features that are described in the context of an embodiment may correspondingly be applicable to the other embodiments, even if not explicitly described in these other embodiments. Furthermore, additions and/or combinations and/or alternatives as described for a feature in the context of an embodiment may correspondingly be applicable to the same or similar feature in the other embodiments. [0027] In the context of various embodiments, the articles “a”, “an” and “the” as used with regard to a feature or element include a reference to one or more of the features or elements. [0028] In the context of various embodiments, the phrase “at least substantially” may include “exactly” and a reasonable variance. [0029] In the context of various embodiments, the term “about” or “approximately” as applied to a numeric value encompasses the exact value and a reasonable variance. [0030] As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items. [0031] As used herein, the phrase of the form of “at least one of A or B” may include A or B or both A and B. Correspondingly, the phrase of the form of “at least one of A or B or C”, or including further listed items, may include any and all combinations of one or more of the associated listed items. [0032] As used herein, the expression “configured to” may mean “constructed to” or “arranged to”. [0033] Various embodiments relate to Information Technology (IT) protocols, more specifically, methods for securely offloading password hashing to a client. Client-side password hashing, or abbreviated as Clipaha, provides a system and a method to perform password stretching on the client, while addressing security issues found in existing work. Clipaha is robust to a broader range of attacks compared to existing work and covers important and complex usage scenarios. Clipaha is readily deployable on both embedded devices as well as systems (e.g. highly constrained server devices) with complex authentication requirements such as database migrations or accounts identified by multiple usernames. In other words, Clipaha does not compromise on the security compared with server-side approaches and allows stronger user authentication in highly-constrained devices. This may be evident by its demonstrated security, an analysis on how to it may be used to securely implement basic and complex authentication related flows, provision of a working implementation, a successful deployment on an embedded device possibly with limited resources such as in an ESP8266 (an embedded wireless device popular on Do It Yourself (DIY) environments featuring an 80 MHz processor and 80 KiB of memory for user data), a benchmark of the resulting code on several classes of hardware and software involving different systems to understand the limitations of mixed Javascript and Webassembly approach faces. [0034] Furthermore, a Clipaha library (implemented in the form of a Javascript, and optionally, Webassembly library) is shown to perform about two times faster than existing approaches, avoid user enumeration by not depending on the user database other than for credential validation, avoid salt collisions through the use of unique and clearly delimited salt values, capable of being integrated into a system in less than one hour as well as capable of running on some devices where other existing libraries have failed. [0035] Details will be discussed later on. [0036] FIG. 1 shows a flow chart illustrating a method 100 for securely manipulating a password hash, according to various embodiments. In Step 102 of the method 100, a SALT generation function may be executed, by a client associated with a user, to provide a globally unique SALT value, wherein the client (e.g. 212 of FIG. 2) is part of a client- server system (e.g.210 of FIG.2). In Step 104, the globally unique SALT value may be combined with a password hashing function, by the client, to generate and provide the password hash of a user-provided password of the user. In various embodiments, the step of executing the SALT generation function may include generating the globally unique SALT value including a globally unique system identifier of the client-server system, and optionally a username of the user. Here, the username may not be included in the globally unique SALT value if only one password exists. The step of generating the globally unique SALT value may include delimiting the globally unique system identifier. [0037] In other embodiments, the step of executing the SALT generation function 104 may include combining a globally unique system identifier of the client-server system with a username of the user to generate the globally unique SALT value. When the username is included as part of the password hash calculation on the client, provision of the username may be optional. For example, when the password hash includes the username, the client may choose not to send the username and the server may check for the presence of the password hash and optionally associate the username or an authentication entity associated with the username on the database, if any, to the client. [0038] The step of combining the globally unique system identifier and the username may include delimiting the globally unique system identifier, or the username, or both the globally unique system identifier and the username. [0039] The method 100 may further include prior to executing the SALT generation function at Step 102, canonicalizing the username. [0040] In the context of various embodiments, the term “manipulating” may be referred to as generating, using, modifying, configuring, or implementing. [0041] The term “combining” may mean and is not limited to prepending, appending, or mixing. The term “client” refers to a device, computer, or software program that connects to and uses the resources of a remote computer or server. A user may use a client to gain access to these remote resources. For example, the client may be associated with the user by being at the user’s end. The user may use the client to create or log into a user account for a service in a network. In the context of various embodiments, the user may be an actual owner of the user account, or any other entity that tries to access the account. The user may be a human or a non-human, e.g. an artificial intelligence (AI) system, a sensor, or an actuator. In other words, the user may be a basic identification entity in the context of who or what the client says to be. [0042] For example, the method 100 (or also referred to as the computer-implemented method) may be based on the concept of client-side password hashing (Clipaha) and provide a Clipaha salt generation function. FIG.4 shows a schematic representation of the concept of Clipaha that is in comparison to a schematic representation of an existing server- side hashing as seen in FIG.5. A secure one-way function protects stored passwords (e.g., a cryptographic hash) ^^(. ) including a random salt s prepended to the password p to make the password unique and avoid equal passwords from being easily recognized during dictionary attacks. As shown in FIG. 5, the triplet 〈 ^^, ^^, ^^( ^^ ∥ ^^)〉 is stored in the server database, so the hash function has to be computed at every access. To protect from dictionary attacks on the database itself, with the advent of powerful GPU, FPGA, and ASIC implementations to accelerate such attacks, the complexity of the hash functions has increased. Meanwhile, Clipaha moves the resource-intensive hash function ^^( ^^ ∥ ^^) to the client, denoted as ^^( ^^ ∗∥ ^^) in FIG. 4. The salt s∗ is not a random string generated and maintained by the server but instead, is a deterministic string derived from the username u and a globally unique string, e.g. the server’s domain name. The server (e.g.214 of FIG. 2) only has to compute a low-cost hash function ℎ(. ), e.g. SHA-256, to prevent replay attacks of leaked password database entries and direct use of leaked database entries to access the server. The low complexity of computation, communication, and storage at the server allows Clipaha to run on embedded devices. [0043] In other words, the method 100 may efficiently and securely move password hashing to a client to solve the issue of storing password hashes, while requiring (a) a salt value globally unique to both user and the system, and (b) knowledge of the hash function to use and the parameters to use it with. Providing these, in a way that does not allow enumerating the user’s presence on the system nor introduces other security issues, is rather complex, especially when it comes to the salt. Nevertheless, the method 100 according to various embodiments is able to move the password hashing step to the client without introducing new security risks in the process and encrypting client-stored hashes in a way that only the targeted server is able to recover them. The solution offers hash parameters known at compilation time, uses only user-provided or non-user specific server-provided data for computation, and enables complex use-cases like database migration or password storage to be implemented on the client for later use. [0044] The method 100 may further include encoding, by the client, the password hash by using at least one of: compile-time hash function parameters, single-instruction-multiple- data (SIMD) or prefetch instructions. Statically (i.e. compile-time) hash function parameters may be used and this significantly improves the performance of the resulting hash function. Heavy use of SIMD instructions and prefetch instructions in the target language may also be used to improve performance even more. [0045] In various embodiments, the method 100 may further include sending, by the client to a server (e.g.214 of FIG.2) of the client-server system (e.g.210 of FIG.2), registration information provided by the user, the password hash, and optionally, the user-provided password, wherein the registration information include the username; optionally validating, by the server, the registration information and optionally the user-provided password; and storing, in a database accessible by the server, the password hash along with the username and optionally the registration information. With that, a registration process may be performed. [0046] In other embodiments, the method 100 may further include receiving, by a server of the client-server system, the password hash; hashing, by the server, the password hash by using a hashing function to obtain a server-hashed password hash; and comparing, by the server, the server-hashed password hash and a validator placed in trust of the server to obtain an indicator, wherein based on the indicator, the server associates with the user to authenticate an identity of the user. The validator may be kept anywhere the server trusts. In other words, the method may further include hashing the (user-provided) password hash on the server using the hashing function and then comparing the result with that, the server associates with the provided user. If the indicator represents a successful comparison, access to an account of the user will be allowed. If the indicator represents a failed comparison, access to the account will be denied. With that, for example, Clipaha’s server- side hashing process for logins may be performed, while preventing pass-the-hash attacks. [0047] In various embodiments, the hashing function may include a lightweight hashing function, or a keyed hashing function. [0048] The method 100 may further include performing multi-factor authentication to provide an additional proof of the identity of the user, or a password authenticated key exchange to verify the password hash to mutually authenticate the client and the server, or a hybrid exchange to authenticate the client by verifying the client’s knowledge of the user- provided password, and the server by using a way other than the server’s knowledge of the user-provided password. For example, the way other than the server’s knowledge of the user-provided password may involve a private key or a certificate. [0049] In yet other embodiments, the method 100 may further include combining, by the client, the globally unique SALT value with the password hashing function to generate and provide a replacement password hash of a replacement user-provided password; additionally receiving, by the server, the replacement password hash; optionally receiving, by the server, the replacement user-provided password, or the user-provided password, or the username; and upon successfully authentication of the identity of the user, storing, in a database accessible by the server, the replacement password hash in place of the password hash stored in the database, consequently performing a change of password. The replacement user-provided password and the user-provided password may be optional and may only be needed if the server needs to perform password policy check. For example, password policy check may involve ensuring that the new (replacement) password has not been used before. [0050] Basically, prior to allowing a password change, the requestor for the password change needs to be verified as who the requestor says to be because the requestor may be authenticated earlier and this can be verified, or because the requestor may be authenticated on the spot by providing the hashed password. In other words, for the password change procedure, the server minimally requires the replacement password hash and the indicator of a valid authentication (or the like, e.g. a session identifier for stateless protocols, a valid session for stateful protocols, or the password hash optionally with the username). For example, after authentication, the Secure Shell (SSH) Protocol may mark the connection as authenticated and associate the user information to it which defacto authenticates any future requests over the connection. In the Hypertext Transfer Protocol (http), a cookie may be set to allow identifying future requests since http is stateless. In other words, http makes the client send the cookie value on future requests to prove its identity. More specifically and optionally, Cross-Site Request Forgery (CSRF) protection, typically a token, may be used with http to ensure that the request is legitimate. [0051] In various embodiments, the method 100 may further include caching, by the client, the password hash. [0052] The method 100 may further include decryption of the user-provided password (hashed or not) to optionally hash the decrypted data on the server using a password hashing function, and then compare the result with that the server associates with the provided user. [0053] Various embodiments may provide one or more non-transitory computer readable storage media each having stored thereon at least part of a processor-executable software instruction set, wherein the processor-executable software instruction set is configured to cause one or more processors to execute a method 100 for securely manipulating a password hash, in accordance with various embodiments. For example, the one or more non-transitory computer readable storage media may store codes for functions run on the client, that may be (but are not limited to being) stored on the client, or in a cache from a prior execution. It should be appreciated that codes for functions run on the client may alternatively be sent by the server or compiled from source by the client using server- provided parameters. Additionally, or alternatively in another example, the server may include the one or more non-transitory computer readable storage media to store codes on the server. In yet another example, the one or more non-transitory computer readable storage media may be included in a part of a platform trusted by the server to store codes on the server. [0054] FIG. 2 shows a schematic representative view of a client-server system 210 involving secure manipulation of a password hash, according to various embodiments. The client-server system 210 may include a client 212 configured to execute a SALT generation function to provide a globally unique SALT value and combine the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password of a user; and a server 214 configured to receive the password hash from the client 212. The server 214 and the client 212 may be in communication with each other, as denoted by a line 216. The client may be associated with the user. For example, the client may be at the user’s end. [0055] In various embodiments, the client 212 may further be configured to generate the globally unique SALT value including a globally unique system identifier of the client- server system 210, and optionally a username of the user. In an example, the globally unique SALT value may be the globally unique system identifier itself when only one password exists. In another example, the username may be included in the generated globally unique SALT value when more than one account or more than one password exists in the client-server system 210. [0056] In other embodiments, the client 212 may further be configured to combine a globally unique system identifier of the client-server system 210 with a username of the user to generate the globally unique SALT value. [0057] The client 212 may further be configured to perform at least one of: canonicalizing the username; or delimiting the globally unique system identifier; or delimiting the username. In other words, the canonicalization, or the delimitation, or both the canonicalization and the delimitation may be performed. [0058] The client 212 may further be configured to encode the password hash by using at least one of: compile-time hash function parameters, single-instruction-multiple-data or prefetch instructions. [0059] The client 212 may further be configured to cache the password hash. [0060] In various embodiments, the server 214 may further be configured to: receive, from the client 212, registration information provided by the user, the password hash, and optionally the user-provided password, wherein the registration information includes the username; optionally validate the registration information and optionally the user-provided password; and store, in a database accessible by the server 214, the password hash along with the username and optionally the registration information. For example, the database may be an external database. Here, the client-server system 210 may be configured to perform a registration process, e.g. as described for the method 100. [0061] In various embodiments, the server 214 may further be configured to: hash the password hash by using a hashing function to obtain a server-hashed password hash; and compare the server-hashed password hash and a validator placed in trust of the server 214 to obtain an indicator, wherein based on the indicator, the server 214 associates with the user to authenticate an identity of the user. The hashing function may include a lightweight hashing function, or a keyed hashing function. Here, the client-server system 210 may be configured to perform a login process, e.g. as described for the method 100. [0062] The client-server system 210 may further be configured to perform multi-factor authentication to provide an additional proof of the identity of the user, or a password authenticated key exchange to verify the password hash to mutually authenticate the client 212 and the server 214, or a hybrid exchange to authenticate the client by verifying the client’s knowledge of the user-provided password, and the server by using a way other than (or different from) the server’s knowledge of the user-provided password. [0063] In various embodiments, the client 212 may further be configured to combine the globally unique SALT value with the password hashing function to generate and provide a replacement password hash of a replacement user-provided password, and wherein the server 214 may further be configured to: additionally receive, from the client 212, the replacement password hash; optionally receive, from the client, the replacement user- provided password, or the user-provided password, or the username; and upon successfully authentication of the identity of the user, store, in a database accessible by the server 214, the replacement password hash in place of the password hash stored in the database, consequently performing a change of password, e.g. as described for the method 100. [0064] In various embodiments, the client-server system 210 may be configured to perform a method 100 for securely manipulating a password hash, in accordance with various embodiments. [0065] FIG.3 shows a flow chart illustrating a method 320 for securing a user-provided password in a client for recovery only by an authentication server, according to various embodiments. In Step 321 of the method, a password hash may be provided by the client (e.g.212 of FIG.2). The password hash may be obtained from a method 100 (FIG.1) and stored in a database accessible by a server (e.g. 214 of FIG. 2), preferably during a registration process of the method 100. The password hash may alternatively be obtained by using a lightweight hash of the user-provided password by the client, and in one example, such password hash may be salted, while in another example, such password hash may not be salted. In Step 322, a public key and a private key may be generated and stored by the server. In Step 324, the public key may be received from the server by the client. In Step 328, the password hash may be encrypted based on (using) the public key by the client to obtain an encrypted password hash. In Step 330, the encrypted password hash may be stored by the client in a storage medium, for example, a password manager or other storage media. The encrypted password hash may be optionally associated with a username of a user and an identifier of the server. In this context, the username may be the password hash or the username may be included in the encrypted data/encrypted password hash. Usually, the username for the user to choose the right credentials is kept only if more than one username is stored on the same client. In Step 332, the encrypted password hash and optionally the username may be received from the client by the server. In Step 334, the client may be authenticated as the user by the authentication server. The authentication server may be the server (214 of FIG. 2). The step of authenticating the client 334 may include the encrypted password hash being decrypted using the stored private key 336; the decrypted password hash being optionally hashed using a hash function 338 (by the server); and determination 340 of the decrypted password hash or the optionally hashed decrypted password hash being the same as a value associated with the password hash previously stored in the database. Optionally, the determination step 340 may further include determination of the decrypted password being valid data. For example, the hashing function carried out by the server may include a lightweight hashing function, or a keyed hashing function. [0066] The step of providing the password hash 321 may include obtaining, by the client, the username and the user-provided password 326; hashing, by the client, the user-provided password using the method 100 according to various embodiments to obtain the password hash 327; and storing the password hash in the database 341. For example, the steps 326, 327 and 341 may be performed during a registration process. [0067] In other words, the method 320 is for binding stored credentials and more specifically, relates to a mechanism (Password to Token, “Pato”) by which a server provides a long-term public key that clients use to encrypt stored credentials. Such encrypted credentials can then be used instead of the password to authenticate the client. The random oracle model proves the security of the algorithm based on the method 320. In some circumstances where additional data is encrypted or at least authenticated on encryption, this may be used so that multiple clients, e.g. industrial internet of things (IIoT) sensors and actuators, interacting through a central server using the same password with the same server, may remain secure even if some of them are compromised. Optionally, communication may be assumed to happen over a secure channel on which the client has verified the server’s identity. A possible example may be using transport layer security (TLS) and a certificate signed by a trusted certification authority. [0068] For example, client provisioning may be done as follows:- a. The server provides the client its long-term public key. b. The client generates and encrypts (RSA style exchanges), or derives (Diffie-Hellman style exchanges), a random symmetric encryption key. c. The client uses a secure symmetric authenticated encryption scheme, keyed using the random symmetric key from the prior step b., (e.g. a “Box” algorithm) to encrypt the credentials for storage (along with any additional data that may limit the usage of the key). If the server has not been given the password earlier, the client can now send its (encrypted) password to perform registration. d. The client stores: the output of the “Box” algorithm that includes the result from the prior step; the encrypted symmetric key (RSA style exchanges) or, alternatively, the ephemeral public key (Diffie-Hellman style exchanges). Optionally, a hash of the server’s public key may be stored by the client to ease the handling during key rollover. e. Optionally, any private key shares (or key material) generated by the client (Diffie- Hellman style exchanges) and all unencrypted symmetric keys (including plain password) are purged. Doing so ensures that only the owner of the server’s private key recovers the stored credentials. [0069] Authentication of provisioned clients is done as follows:- i. The client sends the encrypted credentials along with the additional data that was stored. Since the password ceases to be present on the client after provisioning, the password cannot be recovered from the information stored on the client, thereby being resistant to attacks performed by malwares, e.g. RedLine. ii. The server uses its private key and the “Box” algorithm to decrypt the credentials and additional data from the encrypted data sent by the client. iii. The server ensures that any additional constraints, asserted by the additional data that was decrypted, are met. iv. The server proceeds with authentication as usual using instead the decrypted credentials. [0070] The “Box” algorithm described in more detail later on is an example for realizing the method 320. [0071] FIG. 6 shows a flow chart illustrating a method 660 for securing a user-provided password in a client for recovery only by an authentication server, according to other embodiments. In Step 662 of the method 660, a registration process may be provided. The registration process 662 may include obtaining, by the client (e.g.212 of FIG.2), the user- provided password of a user and optionally a username of the user 664; and associating a value with the user-provided password 666. In Step 668; a setup process may be provided. The setup process may include generating and storing, by a server (e.g.214 of FIG.2), a public key and a corresponding private key 670. In Step 672, a provisioning process may be provided. The provisioning process 672 may include receiving, from the server by the client, the public key 674; encrypting, by the client, the user-provided password based on the public key to obtain an encrypted password value 676; and storing, by the client, the encrypted password value in a storage medium 678, e.g. a password manager or other storage media. The encrypted password value may be associated with the username and an identifier of the server. The stored encrypted value may be recovered by the client. In Step 680, an authentication process to authenticate the client by the authentication server may be provided. The authentication server may be the server (214 of FIG. 2). The authentication process 680 may include retrieving, from the client and by the server, the stored encrypted password value 682; receiving, from the client by the server, the retrieved encrypted password value and optionally the username 684; decrypting the retrieved encrypted password value using the stored corresponding private key to obtain a decrypted value 686; and determining that the decrypted value is the same as the value associated with the user-provided password 688. [0072] In various embodiments, the provisioning process 672 may further include prior to the step 676 of encrypting the user-provided password, obtaining the user-provided password and optionally the username, by the client, if the user-provided password and optionally the username are not stored during the registration process 662; and associating the value with the user-provided password obtained during the provisioning process 672. [0073] In other embodiments, the step 666 of associating a value with the user-provided password during the registration process 662 may further include transforming, by the client, the user-provided password; receiving, from the client by the server, the transformed user-provided password; transforming, by the server, the transformed user-provided password to obtain a first transformed value; and storing, by the server, the first transformed value. The step 676 of encrypting the user-provided password during the provisioning process 672 may include encrypting, by the client, the transformed user- provided password based on the public key to obtain the encrypted password value. After the step 682 of retrieving the stored encrypted password value, the authentication process 680 may further include transforming, by the client, the retrieved encrypted password value to obtain a transformed retrieved value; receiving, from the client by the server, the transformed retrieved value and optionally the username; and transforming, by the server, the transformed retrieved value to obtain a server-transformed value. The step 686 of decrypting the retrieved encrypted password value during the authentication process 680 may include decrypting the server-transformed value using the stored corresponding private key to obtain the decrypted value. After decrypting the server-transformed value, the authentication process 680 may further include transforming, by the server, the decrypted value to obtain a second transformed value; retrieving, by the server, the stored first transformed value; transforming, by the server, the stored first transformed value to obtain a third transformed value. The step of determining 688 during the authentication process 680 may include determining that the second transformed value is the same as the third transformed value. [0074] In the context of various embodiments, the term “transforming” may mean performing a function with known input parameters one of which is the parameter to be transformed. For example, “transforming” may include “hashing” with or without a salt and with or without a key, functions such as addition, subtraction, or other mathematical or string operations, encryption, decryption, padding or unpadding. [0075] In various embodiments, the step of encrypting the transformed user-provided password during the provisioning process 672 may include transforming, by the client, the user-provided password to obtain a provisioning transformed user-provided password value; and encrypting, by the client, the provisioning transformed user-provided password value based on the public key to obtain the encrypted password value. For example, the provisioning transformed user-provided password value may be obtained based on a function or a set of functions that may be the same or may be different from those used during the registration process 662 to obtain the transformed user-provided password. [0076] It should be appreciated that in some embodiments, the function or set of functions for transforming or transformation performed during the registration process 662 may be the same as those used for the provisioning process 672 and/or the authentication process 680. In alternative embodiments, the function or set of functions for transforming or transformation performed during the registration process 662 may be different from those used for the provisioning process 672 and/or the authentication process 680. [0077] The step of encrypting the transformed user-provided password or encrypting the provisioning transformed user-provided password value may include padding the transformed user-provided password or the provisioning transformed user-provided password value; and encrypting the padded transformed user-provided password or the padded provisioning transformed user-provided password value using public key encryption to obtain the encrypted value. Decrypting the server-transformed value may further include unpadding the decrypted value. The public key encryption may be any suitable public key encryption scheme. [0078] In an example of the method 660 may be as follow. Assume hash function h and h' that may be salted or not and may be keyed or not, encryption function e(K+) and d(K-) and symmetric encryption function e(k) and d(k), where K+ may represent a public key, K- may represent a private key and k may be a key for symmetric encryption. During the registration process, p'=h(p), r =e(k, h'(p')), where p represents the original (user-provided) password, p' may refer to the transformed user-provided password, r may be the first transformed value. In provisioning, p''=h(p) where p'' may be the transformed user- provided password, q=e(K+,p''), where q may be the encrypted password value. During authentication, the server receives q from the client and recovers r then checks that h'(d(K- ,q)) == d(k,r). This is correct because after recursively substituting terms, the following is obtained: h'(d(K-,e(K+,h(p)))) == d(k,e(k,h'(p'))). By replacing p', the following is obtained: h'(d(K-,e(K+,h(p)))) == d(k,e(k,h'(h(p)))). Simplification may be carried out by d(K-,e(K+,x)) = x and d(k,e(k,x))=x since the inverse function f⁻1 of the first function f is applied to the result of f. By doing so, h'(h(p)) == h'(h(p)) is obtained. Since h and h' are deterministic, the equality holds (if the value of p on both sides of the equation is the same). [0079] Furthermore, any chain of transformations described on method 660 can be evaluated for correctness by using the same technique of first recursively substituting the terms of the final comparison, then simplifying the application of an inverse function f⁻¹ to its corresponding function f, also taking into account that this simplification is possible when all of the functions applied between f⁻¹ and f are homomorphic regarding f and finally checking that the resulting simplified comparison contains the same sequence of functions applied on both sides and that said sequence only contains deterministic functions, that is, functions that given for all of the possible values of the input domain will always return the same output value from their image corresponding to said input value. As an example, if f(2) returned 4 and later f(2) returned 6, it would not be deterministic because it returned different values despite the same input value being provided. [0080] As a consequence of the above, a chain of transformations can, for example, be built as follows: apply any set of transformations of the user-provided password by the client and the transformed user-provided password by the server during the registration process (662 of FIG.6); perform recursive substitution and simplification to the equation defining the resulting value (e.g. the first transformed value); apply a subset of the transformations from the resulting equation on the user-provided password by the client during the provisioning process 672; apply a set of transformations for which an inverse exists on the stored encrypted password value during the authentication process 680; apply the inverse transformations to those applied on the transformed stored encrypted password value to obtain a server-transformed value; further apply a subset of the transformations that where not applied when calculating value during the provisioning process so that only functions for which an inverse exists remain to be applied, on the second transformed value; applying the inverse functions to the first transformed value, on the third transformed value. When performed correctly, the resulting values of the comparison on the second transformed value and the third transformed value will be correct when tested as explained above. [0081] While each of the methods 100, 320, 660 described above is illustrated and described as a series of steps or events, it will be appreciated that any ordering of such steps or events are not to be interpreted in a limiting sense. For example, some steps may occur in different orders and/or concurrently with other steps or events apart from those illustrated and/or described herein. In addition, not all illustrated steps may be required to implement one or more aspects or embodiments described herein. Also, one or more of the steps depicted herein may be carried out in one or more separate acts and/or phases. [0082] The advantages of the client-side approach may include but is not limited to: having similar security to server-side approaches; having computational resources and energy consumption for the authentication process being smaller on the server (and on certain clients); having almost no computation on the server, where the effort is made by the client who tries to authenticate itself; lowering implementation costs; and securing storage of passwords on client side for faster and more energy efficient authentication on future iterations. The client-side approach may be applied in a large array of “use cases” beyond plain registration, authentication, password change and password recovery. For example, implementation recommendations may include for: handling repeated password inputs; migration from server-side hashing databases; migration to improved client-side hashing databases; handling of multiple usernames associated with an account; caching of password hash computations; storage of password-hashes on the client with security properties equal to those of a token; and efficiently usage of credentials for non-human users. [0083] Examples of the client-side approach will be described in detail below. A. Clipaha’s Design [0084] In order to ensure that strong password hashing solutions can be used in as many environments as possible, it is proposed for the computational load to be moved to the entity trying to authenticate itself (client) instead of the authenticator (server). With server relief, the client provides the brunt of the work to hash the password. [0085] In doing so, the following requirements may appear: providing the configuration parameters for the hash algorithm (thus, not requiring software developers to choose relevant security parameters); providing a unique salt value for the hash algorithm to ensure unique results; ensuring the user gets the correct salt value; preventing attacks from online and offline attackers (e.g. being resistant to salt collisions, user enumeration, and/or pass- the-hash attacks); ensuring the used password hash algorithm is as at least as secure as if it would be if performed by the server; and keeping the performance impact to legitimate users as low as possible. [0086] While the provision of the configuration parameters and the unique salt value may be typically done by the server once the user identifier is provided, such system may be open to a user enumeration attack, e.g. as online attackers can easily detect the lack of salt for unregistered users or see how they change over time. Thus, instead, a global set of parameters is proposed to be used and a hash value is derived by combining the user identifier (usually the username or e-mail address) with another string which uniquely identifies the whole user database. This string may be referred to as the database identifier. However, this approach may introduce an additional issue in that if the same user has different usernames, the resulting salt and corresponding hash would change. Looking up the appropriate canonical username is not a valid solution as it allows user enumeration. To address this and satisfy the requirement of ensuring that the user gets the correct salt value, the username is canonicalized before use. Canonicalization is the process of converting data that has more than one possible representation into a standard, normal or canonical form. [0087] Additionally, a choice must be made as to whether to publish the database identifier or not. If the database identifier is kept secret into the user database, then precomputation attacks may be noticed through log analysis because the attacker would still need to request the hash for each targeted username. In this case, as there would always be a valid value to return, even for users not in the database, the attacker does not gain any information about which user identifiers are present. [0088] As an alternative, the database identifier may be made public, and the client may be provided with the canonicalization rules. By doing so, the whole operation may be performed directly on the client without any interaction from the authenticator until the client tries to authenticate itself. Such an approach presents other advantages such as making it easier for a client to see if it can reuse cached credentials to avoid recalculation. This design choice also ensures that the developer does not try to access the database, therefore, avoiding user enumeration attacks. Preventing user enumeration is a main argument to opt for this approach in Clipaha’s design. [0089] To circumvent enumeration attacks and at the same time, avoid salt collisions, Clipaha does not involve the server in the hashing process itself and instead, lets the client calculate the salt locally based on a deterministic database identifier (i.e., the server’s domain) and username. This choice deviates from the standard approach of using a random salt. It may be argued that only uniqueness, not randomness, is required to avoid salt collisions. Therefore, credential bruteforcing does not gain a significant structural advantage by having a predictable, low-entropy salt compared to the case where it has access to a random, high-entropy one. Clipaha’s design may include the same or like elements as those of the method 100 of FIG. 1, and as such, the like elements may be as described in the context of the method of FIG. 1, and therefore some corresponding descriptions may be omitted here. [0090] The resulting algorithm to perform the password hashing is described on Algorithm 1. [0091] Algorithm 1 – Clipaha’s password hashing process function CLIPAHAHASH( ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^) ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ← CANONICALIZEUSERNAME( ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^) ^^ ^^ ^^ ^^ ← DELIMIT( ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^)‖DELIMIT( ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^) return PASSWORDHASH( ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^) end function [0092] As seen in Algorithm 1, CLIPAHAHASH performs three steps. First, CANONICALIZEUSERNAME applies any transformations to obtain the canonical username (e.g., lowering the case to attain case-insensitive usernames). This ensures that the system returns the same hash for usernames that should be considered equivalent. To avoid user enumeration attacks, CANONICALIZEUSERNAME may operate offline and use only the username as input. Second, to further reduce the risk of salt collisions, DELIMIT ensures the canonical username and the database identifier do not mix together when their strings are concatenated. For example, the 32-bit little endian representation of the size of the input may be prepended to the input. Third, the hash of the password and the salt are computed and returned using a strong hash function PASSWORDHASH. For the PASSWORDHASH function, Argon2 may be chosen to satisfy the requirement of being at least as secure as if it would be if performed by the server. [0093] Using Argon2 requires setting some input parameters, e.g. the size of the memory and time factors of the algorithm and the number of parallel threads to use. Instead of giving the developers full freedom of choice, only four hard-coded defaults: low, medium, high, and ultra are provided. These hardcoded defaults are named after the security level they provide (at the expense of performance and cross-compatibility). The usage of hardcoded parameters satisfies the requirement of providing the configuration parameters for the algorithm while the four choices allow the developers to balance between the requirement of being at least as secure as if it would be if performed by the server and the requirement of keeping the performance impact to legitimate users as low as possible. [0094] Meanwhile, Algorithm 2 describes the server-side hash. [0095] Algorithm 2 – Clipaha’s server-side hashing process function CLIPAHASERVERHASH( ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ℎ) return HASH( ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ℎ) end function [0096] In Algorithm 2, the input to CLIPAHASERVERHASH would be the output of CLIPAHAHASH (of Algorithm 1). This function only performs a call to a one-way function HASH, which does not need to be computationally expensive. This prevents pass-the-hash attacks. Otherwise, an offline attacker (with read-only access to the database) can replay the entry in the database to access the service. [0097] Evaluating system support for the different settings only took into account systems targeting humans entering their passwords and not embedded devices. Non-human authentication will be explained later on. [0098] Clipaha was compared against two existing approaches, namely, Crackstation’s approach and Libsodium’s approach in terms of their security against different attacks, as shown in Table 1. [0099] Table 1 Approach Salt Enumeration Precalculation Reference library Collision available Libsodium Secure Not secure Not secure Partially Crackstation Not secure Secure Not secure Yes Clipaha Secure Secure Not secure No [0100] The security of Clipaha, a client-side hashing primitive, addresses the vulnerabilities affecting at least the current state of the art as demonstrated in the Crackstation’s approach and Libsodium’s approach. Details will be discussed in Section B below. B. Security Evaluation of Primitives [0101] When evaluating the security of a system, attack economics should be considered: if ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ≫ ^^ ^^ ^^ ^^ ∙ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^, the attacker will not perform the attack. One has also to consider the different kinds of intentions and advantages an attacker may leverage. Thus, an online and offline adversary model. Finally one should consider the attacks such adversaries may use against the system and if mitigations exist. B1. Adversary Model [0102] Attackers’ primary objective is obtaining valid user credentials to give them access to the system and the ability to move laterally to other systems where the credentials have been reused. In most cases, attackers also have as an objective to access the service without authorization. When considering the issues in password hashing, two types of attacker models, namely online and offline attackers, may be considered. On one hand, online attackers have access to the login system and try to use any available side-channel to learn information about the users on the system which they can make use of. On the other, offline attackers have full access to the user database in one or more systems and try to gain as much additional information from their data as possible. Additionally, when modelling these attacks, it should be taken into account that an online attacker may eventually become an offline attacker. One such example would happen after breached user data is publicly exposed. [0103] An online attacker may gain information not only directly from the responses but also by comparing responses over time or by using side-channels like, for example, timing differences. When presented with an online attacker, client-side approaches have to face the same issues as server-side approaches: credential stuffing and user enumeration. Credential stuffing (or interchangeably referred to as credential bruteforcing) involves an attacker trying credentials directly on the server to try to guess a valid pair. The effort for successful credential bruteforcing depends linearly on the computational cost of the hash function and exponentially on the entropy of the passwords. User enumeration involves attempting to see if a user is registered on the system or not by directly querying the database or by detecting differences in responses. [0104] Offline attackers also present similar challenges in both client and server-side approaches. After a breach, the attacker will try to crack the stored credentials prioritizing those that are more interesting. By allowing an attacker to make a guess on all the colliding credentials with a single hash operation, salt collisions put credentials at risk. Additionally, an attacker can see with little computational effort whether the same password was used on entries with colliding salts. On top of that, client-side approaches introduce the risk for pass-the-hash attacks. In a pass-the-hash attack, the attacker tries to use the already hashed credential stored in the breached database. Such an attack would work not only on the site itself but also on other sites with the same salt, password and hash parameters. [0105] From the combination of both adversaries, precalculation attacks arise. In such an attack, the online attacker may obtain the hash parameters beforehand and invest the resources to crack the password early hoping to use these hashes when becoming an offline attacker. [0106] Some of these issues may be mitigated with appropriate measures on the server implementing the authentication. First, credential stuffing must be mitigated on the server- side using well-known techniques. Second, performing a fast hash on the server side using a random salt stored with the credential over the already hashed credentials provided by the user preventing pass-the-hash attacks and detecting password reuse. Finally, the client- side hashing approach is left to solve salt collisions, user enumeration and precalculation attacks. These attacks are analyzed below, with the summary of the results provided in Table 1 above. B2. Salt Collisions [0107] A salt value is added to passwords in order to increase an offline attacker’s effort when performing a dictionary attack against a large password collection. In salt collision, two or more passwords are hashed using the same: salt, hash function, and hash parameters. Since an attacker may join all of the accounts sharing the same salt, only one hash operation may be needed to test a password guess against all of them simultaneously. Thus, the effort of the attacker would increase proportionally with the number of different salt values used by the targeted accounts. Similarly, an attacker can create rainbow tables to perform a time- memory trade-off for the attack if the number of different salts is small. To avoid such trade-offs, the implementation has to generate the salt in a way that ensures uniqueness both across users in a system and across different systems, especially when the username is similar. [0108] For Libsodium, this attack is only possible if there is a flaw in the random number generator (RNG) used by the client when registering a user. Otherwise, the possibility of an attack follows the same bounds of the known birthday problem which depends on the square root of the length of the salt. Therefore, in general, the system may be considered secure when using strong enough parameters. [0109] Regarding Crackstation, there are two problems. First, this attack depends on how the salt is generated. If the username and the site’s domain name are concatenated, a collision may happen when these overlap across domains. For example, for alice on email.com, the salt would be the same as for alicee on mail.com: aliceemail.com. Additionally, this risk may be present for all usernames shared across different systems who have the same database identifier. For example, when different services are provided under the same domain name. Second, because of the underspecification, other instances of salt collision may arise as a result of using different approaches to concatenate the username and the database identifier, e.g. user abc.com on def.com which concatenates username first would share the salt with def.com on abc.com that instead concatenates database identifier first: abc.comdef.com. [0110] With respect to Clipaha, its generated salts are secure against such collisions when considering other systems using the same password and salt calculation method. Clipaha’s security stems from its salt components being unambiguously delimited. Since Clipaha uses a reasonably unique prefix that prefixes the unique database identifier with its size as a 32-bit integer, it is also unlikely that salts generated using other systems will collide. B2.1 Proof of Salt Uniqueness [0111] Theorem B2.1.1. If the set of components is unique, a salt generated using an unambiguous mapping of such components is unique among all similarly generated salts. [0112] Proof of theorem B2.1.1. Given a set of components C = (c1, c2, …) so that C ∈ U, and U represents all possible component sets, a salt ^^ = combine( ^^) is generated and uncombine( ^^) = { ^^′ ∈ ^^|combine( ^^′) = ^^} is defined. Since the mapping is unambiguous then |uncombine( ^^)| = 1. If S was not unique, then ∃ ^^′ ∈ ^^(combine( ^^′) = ^^ ⋀ ^^′ ≠ ^^). As a result |uncombine( ^^)| = |{ ^^, ^^′, ... }| ≥ 2 ≠ 1. This result breaches the unambiguous mapping property creating a contradiction. [0113] Lemma B2.1.1.1. Given a set of components C = (c1, …, cn, cn+1, …, cm) so that (c1, …, cn) is globally unique among all systems using the mechanism and (cn+1, …, cm) is locally unique inside the specific system then C is globally unique amongst all systems using the mechanism. [0114] Corollary B2.1.1.2. If a delimited globally unique string is prepended to a set of delimited strings used to generate a globally unique salt generated using theorem B2.1.1, the result is still globally unique. [0115] Theorem B2.1.2. Clipaha has an unambiguous mapping of generated bits to components. [0116] Proof of theorem B2.1.2. The first four bytes delimit the global identifier length and are followed by exactly the represented number of bytes of a salt identifier allowing to unambiguously recover it from the result. Similarly, the four bytes after the global identifier represent the length of the username and are followed by exactly the length bytes of username. Consequently, recovery is unambiguous. Afterwards, there are no more bits left to map. [0117] Theorem B2.1.3. Salts generated using Clipaha from a locally unique username u and globally unique database identifier i are globally unique. [0118] Proof of theorem B2.1.3. Per Lemma B2.1.1.1, C is known to be unique. Per Theorem B2.1.2, the mapping of bits in S is known to be unambiguous. As the preconditions for Theorem B2.1.1 are satisfied, S is locally unique. Supposing the algorithm identifier is unique (and nobody else uses it), then per Corollary B2.1.1.2 is globally unique. B3. User Enumeration Attacks [0119] In user enumeration, attackers check for the existence of users in the system by directly querying the targeted system or detecting differences in responses. First, to avoid user enumeration attacks, client-side approaches perform any extra server side steps even if the password is wrong to avoid timing side-channels. Second, an attacker can detect changes in password hashing parameters or salts provided by the server for a specific user. Consequently, approaches must ensure all provided data is either global and not depending on the username or constant for a specific username during the whole operation of the system, or the whole database life. [0120] For Libsodium’s approach, this attack only appears in its first form if the developer introduces the timing side-channel. Additionally, this attack is always present in its second form since an attacker can look for changes of the salt provided during login over time. Salt changes happen only after registration or password change, therefore, indicating presence of the account. This attack can be exacerbated when the database canonicalizes usernames but the pseudorandom generator does not. In such a situation, the attacker can just notice whether the salts of two usernames that would result in the same canonical one are the same. [0121] Regarding Crackstation’s approach, this attack is present only in its first form if the developer introduces the timing side-channel. Regarding the second form, Crackstation uses only globally public parameters which guarantees resistance to user enumeration for all accounts, whether the accounts exist or are non-existent. [0122] Clipaha actively tries to prevent the first form of this attack by actively avoiding side-channels when implementing scenarios using the primitive. Also, like Crackstation, Clipaha only makes use of globally public parameters and is therefore not affected by the second attack. B4. Precalculation Attacks [0123] The impact of precalculation attacks is limited from an economical perspective. First, when an algorithm targeted at avoiding GPU, FPGA and ASIC based attacks is chosen, an attacker cannot gain a significant benefit from using such hardware as compared to a normal CPU. For example, Argon2 and Scrypt are resistant algorithms but PBKDF2 is not. Second, an offline attacker benefits economically from this only when the costs of performing computations increased over time. Otherwise, the only gain obtained is a shorter wall time from breach to success. Finally, doing such an attack involves betting on having database access in the future. Consequently, this attack is economically uninteresting unless the attacker aims at a very specific account or has a way to enumerate users. [0124] For Libsodium’s approach, this attack is possible because the salt is provided to the client in plain text. Libsodium minimizes the impact of this attack by using Argon2 or Scrypt. [0125] Regarding Crackstation’s approach, this attack is present for exactly the same reasons. Unlike Libsodium, Crackstation recommends PBKDF2 which can be accelerated by a GPU an FPGA or an ASIC. Such devices reduce the cost for the attacker and make precalculation more economically interesting. This incentive is exacerbated by the fact that such devices may also be used to calculate hashes used for credential stuffing. [0126] Clipaha is also affected since the attacker can calculate the salt. Nonetheless, to minimize the impact, Clipaha uses Argon2id, that works as Argon2i (using data- independent memory accesses) for a first half of the first iteration over the memory and as Argon2d (using data-dependent memory accesses) for the rest, thus providing both protection against side-channel attacks and against brute-force cost savings due to time- memory trade-Off (TMTO). C. Security Evaluation of Scenarios [0127] While most systems just need a process for users to login and, maybe, to register and change their passwords, more complex requirements may also arise. As with any other authentication approaches, implementing these requirements carelessly may result in new security problems arising. To address this risk and ensure that Clipaha can be deployed in such systems, implementation scenarios with a security analysis of those security issues that the primitive cannot fully solve by itself will be described below, where the basic assumptions of the server side when handling the client provided hashes will be introduced, followed by the introduction of five simple authentication scenarios, three complex scenarios and three purely client-side scenarios. Clipaha’s feasibility is demonstrated, making it easier to deploy, and bridging the existing gap by providing implementation approaches to handle complex authentication scenarios and database migrations. C1. Basic Assumptions [0128] It is assumed that communications between client and server happen over a secure channel on which the client has already authenticated the server. One example of such a channel is a TLS connection. This avoids eavesdropping attacks. [0129] For simplicity, reference is made to verifying, inserting and updating the client provided hash on the database with a slightly more complex meaning. In all scenarios where a password hash generated by Algorithm 1 is verified, this should be understood as "rehashed using a fast algorithm with the corresponding salt belonging to the user and then compared for equality. All this is done in constant time, even if the user does not exist". Similarly, when the password hash generated by Algorithm 1 is inserted or updated, this should be understood as "a random salt of at least 128 random bits is generated, the password hash is then rehashed using a fast algorithm and this salt and the result is stored/updated on the database. All this is done in constant time whether the user exists or not". This prevents pass-the hash issues and timing side-channels. [0130] Clipaha is compatible with password authenticated key exchanges (PAKEs), where a cryptographic key is negotiated using the password. When a PAKE is integrated in the process, a password hash generated by Algorithm 1 being verified should be understood as "validated using the PAKE. All this in constant time, even if the user does not exist". Similarly, when the password hash generated by Algorithm 1 is inserted or updated on the database, this should be understood as "the password hash is provided as input to the algorithm that generates the server verifier. This verifier is then stored/updated on the database. All this is done in constant time whether the user exists or not". Again, this avoids timing side-channels and, if the PAKE is well designed, the ability of the attacker using the server verifiers to impersonate the client. [0131] Clipaha is also compatible with Multi Factor Authentication (MFA). If MFAs are in place, their codes should be provided by the client before verification along with the plaintext password and validated during verification. If an action from the server, like sending an short message service (SMS), is required for MFA, it has to be performed after verification succeeds but before any further actions are carried. Additional server actions and MFA value validation should be in constant time and look the same even when the user has no MFA or does not exist to prevent side-channels. C2. Simple Scenarios C2.1 Login process [0132] The login process is fairly straight-forward. Before authentication, the client (e.g. 212 of FIG.2) is provided with the database identifier. Next, the user provides its username and password which are processed by Algorithm 1. The client then sends the resulting hash and the username. The server (e.g.214 of FIG.2) proceeds to verify the hash against the database. If the username exists and the hash matches, the user is allowed in. Otherwise, a generic message similar to "Invalid username or password" is returned to be displayed. Additionally, care must be taken so that the verify operation takes the same amount of time if the user does not exist or the password is incorrect. [0133] User enumeration is avoided because all the data used is either global or directly provided by the user. In the case of using a PAKE, this responsability falls also on the PAKE itself. The risk of credential stuffing is mitigated on the server-side using well known techniques. C2.2 Registration process [0134] During registration of a new user, the server (e.g.214 of FIG.2) sends the database identifier to the client (e.g. 212 of FIG. 2). Optionally, the client verifies the password policy details that are user independent and not confidential (e.g. length or complexity) showing an error if the test fails. The client then sends the registration details and the password both in plain text and hashed using Algorithm 1. The server then validates all fields, including that the plaintext password matches the full password policy. If the verification fails the server returns an error to the client. If all went well, the server inserts the password hash along with the new user in the database (and proceeds with any further steps, like e-mail verification). To avoid user enumeration, if the user is already present, instead of insertion, the existing user is notified through an alternative communication way, but without showing a different error message to the user carrying out the registration. Timing of the insertion and any operations afterwards must be the same whether the user is present or not. [0135] It is assumed that the client can be trusted to send the hashed password matching the sent plaintext password. If these were different, the client may bypass the password policy verification by sending instead a policy-breaking hashed password. Since this only impacts the user purposefully trying to break the policy and is against the user’s interest, the risk of this issue may be deemed low. Despite that, this may be addressed by either computing the hash on the server or, alternatively, by delegating this computation to a trusted and more powerful server. One of the security issues that may arise is that the client sends a plaintext password different from that on the hash. Optionally, the server may perform the hash and policy verification by itself. This may open the server to a DoS attack. Consequently, the risk of this issue may be deemed low since bypassing password policies would be against the user’s interests and, even if done, the impact may be limited to the user’s account. Therefore, client-side verification may be preferred. Regarding user enumeration, this may be avoided or at least minimized by ensuring that the response is the same even if the user is in the database and by keeping timing constant. C2.3 Password change process [0136] To change passwords, the server (e.g.214 of FIG.2) sends the database identifier and the current session’s username. The client (e.g. 212 of FIG.2) then asks for the new password and hashes this new password using Algorithm 1. The client may optionally ask for the original password and if needed to prove its identity, hashes this original password using Algorithm 1 as well, thus taking twice as long. The client then sends the hash(es) and optionally the password(s) to the server. Optionally, the client verifies the password policy details that are user independent and not confidential (e.g. length or complexity) showing an error if the test fails. Optionally, in the case where no session exists or no Cross-Site Request Forgery (CSRF) token is in place, the server may proceed to verify that the old password hash matches the one of the current user. If it does not, it returns an error message to the client. Otherwise, it may optionally check that the new password plaintext complies with the password policy. If similarity to the old password has to be verified, this can optionally be done using the client provided plaintexts. If all goes through correctly, the server updates the database using the new password. [0137] The password change process presents the same challenges and complexities as registration regarding password policy verification. Additionally, a CSRF attack may allow an attacker to change the password to take over an account when the old password is not requested and verified (unlike what may be recommended). In such a case, appropriate measures, like sending the original password hash or optionally using a CSRF token if the original password hash is not sent, have to be taken. Because this process depends on an authenticated session already being in place and only affects the user itself, other security issues are not a direct concern. C2.4 Account recovery process [0138] Account recovery works almost in the same way as password change. The client (e.g.212 of FIG.2) sends a recovery token instead of a password. The client also sends the username, the hash, using Algorithm 1, of the new password, and optionally the plaintext of the new password. Optionally, the client verifies the password policy details that are user independent and not confidential (e.g. length or complexity) showing an error if the test fails. The server (e.g. 214 of FIG. 2) verifies in constant time the correctness of the token and that it belongs to the username, and also verifies the password matches policy. If any check fails, the server returns a message indicating the corresponding invalidity. If all went through, the server updates the user’s password entry on the database. [0139] The security concerns are the same as for password change with two exceptions. First, CSRF is not a concern because token validation is mandatory; and second, recovery tokens must be random and unpredictable enough so that an attacker cannot guess them. Generating at least 256-bits of random data may be secure enough. C2.5 Repeated password input [0140] Some of these scenarios may require that the user enters the password twice for verification. It is preferable to verify they match on the client side to avoid hashing data twice. The security implications of this are the same as for checking password policies during registration, if the client (e.g.212 of FIG.2) cannot be trusted then the check should be done on the server (e.g.214 of FIG.2) instead (verifying the plaintexts which may be hashed on the server). Again, this is costly and since it only impacts the user itself, it is likely not a concern. C3.Complex Scenarios C3.1 Old database migration process [0141] Users may already be registered on a database with an encrypted password that is calculated on the server side. In this situation, the login process remains the same on the client-side, where the client (e.g. 212 of FIG. 2) sends both the hashed and unhashed passwords to the server (e.g.214 of FIG.2). The server performs a hashing round with the legacy algorithm using the plaintext password (even if the user is already migrated or not present) and then verifies in constant time if this hash matches the one corresponding to the user. Finally, the server verifies the client provided hash too (even if the user was not migrated or present). If the verification matching the current user status fails or the user is not present, the message for an invalid username or password is presented and the process stops. Otherwise, the server updates the user’s entry using the client provided hash and marks the account as migrated. [0142] For newly registered users and for users changing their password or recovering their accounts, the usual process already generates a properly migrated password hash to be inserted into the database, so no special considerations are necessary. An exception may be password changes in which the old password is required. In this case, the old password may be validated using the same procedure described for logins, as discussed above. [0143] Eventually all users have their passwords migrated so that the system can revert to the more effcient, client-side process. Alternatively, administrators consider asking users with old passwords to login before a specific date and disable their accounts afterwards so that no login is possible and the old hash calculation is not needed anymore. [0144] By ensuring the operations are the same, whether the user is migrated or not, before failing when a mismatch happens during login, timing side-channels that allow user enumeration may be avoided. Also similar issues, to those mentioned on the registration process regarding trust on the client not bypassing password policies, appear regarding the client providing a password hash matching the plaintext. C3.2 Client-side algorithm migration process [0145] As new and stronger algorithms appear, or as users migrate towards more powerful devices, it may be necessary to migrate to newer algorithms. In this case, all processes remain the same as for old password migration except login which is as described below. [0146] During login, the client (e.g.212 of FIG.2) uses first the new algorithm and sends the hashed password to the server which verifies this hash (failing if the user is not migrated yet). If verification at this step succeeds, so does authentication and this is reported to the client. If the verification fails, the server (e.g. 214 of FIG. 2) increases the failed login counter, stores the used password hash on the client’s session and tells the client to retry. Then, the client uses the old hash algorithm and sends both hashes to the server. The server checks that the session has a stored hash from the prior steps and ensures it matches in constant time (failing when it does not). If it does, the server verifies that the old hash matches the one in the database. If verification fails, or the user is not present, or is already migrated, the server fails with the usual invalid username or password message and deletes the hash stored on the session. Otherwise, authentication succeeds and the server updates the user account using the password hash made with the new algorithm. [0147] This approach avoids user enumeration by avoiding giving information to the client on which specific algorithm to use based on the username and by ensuring that, if the password is wrong, the attacker does not fully know so until the old password hash is also verified. Additionally, this algorithm prevents two-by-one attacks by ensuring that the client only gets one try with the old hash after it has done a try using the new hash (by storing it in the session, validating it on the next step too, and deleting it when the old hash verification fails). This session information must be kept on the server side to avoid replay attacks. Otherwise, all the security assumptions applying to old database migration apply also here. C3.3 Multiple hard to canonicalize usernames [0148] Some systems (e.g. 210 of FIG. 2) use more than one independent user identifier for the same user. One such example are social networks like Twitter where a user can be identified by username, phone number or e-mail address. To address such a requirement, the password handling processes may be modified. The first step is having a password hash on the database for each independent user identifier. Hash verification only compares with the one belonging to the provided username. Registration requires the user providing the hashes for each of the identifiers. In password changes, the server (e.g. 214 of FIG. 2) provides a username list instead of a single username and the client (e.g. 212 of FIG. 2) provides a new password hash for each of the provided usernames (and an old password hash for one of them). Account recovery with client-side hashing works on a similar way by providing the list of identifiers to hash the new password with when the one-time token is valid for the provided username. [0149] As for account migrations, the client keeps the plaintext password until login is finished. If the account is not migrated yet and login succeeded, the server provides a list of user identifiers for which new hashes have to be derived by the client. The client then sends back the results for the server to store. As an alternative, if disabling unused user identifiers is okay, migration can proceed normally without providing any identifier list and the administrators disabling any non-migrated user identifiers after some time has passed. [0150] In this process, user enumerations are mainly avoided by providing the full username list only when the client has successfully authenticated before. Similarly, to avoid birthday attacks, verification is only made against the one verifier belonging to the provided username. Otherwise, the same assumptions as for their original processes apply to the modified ones. C4. Client-side Only Scenarios C4.1 Client-side caching of password hashes [0151] Since the computation result is deterministic, client-side applications may cache the hash computation for later retrieval to save resources. [0152] To avoid credential stuffing, when this caching is done across different applications or domains, the cache ensures it takes the same time to provide the hash as it took to calculate it and that requests are not processed simultaneously. Doing so, prevents timing side-channels which allow guessing if some other application or domain has tried a specific combination of algorithm, database identifier, username and password. Similarly, the keys and the contents of the cache may be used to impersonate users. To reduce the risk of credential stealing, the cache also ensures data is never stored on long term storage without proper encryption. Instead, the cache keeps data only in non-swappable RAM. To reduce remanence and memory starvation by other apps, caches also clear stored entries after some time without use has passed and limit the amount of entries a domain or application can use. C4.2 Password managers [0153] Password managers can interact with the client-side code using Clipaha and provide (along with the plaintext password) the already hashed password and the parameters used. The client (e.g. 212 of FIG. 2) can then use this hash to avoid performing its own calculation. Similarly, the client-side code can send new hashes (along with the input parameters) to the manager for later retrieval. [0154] To avoid pass-the-hash attacks, the manager stores the hashed passwords using the same security measures used for the plaintext. Similarly, the manager also uses the same access policies it would use for the plaintext password. C4.3 Non-human authentication [0155] Services may need to be available to embedded devices that try to authenticate themselves. Assuming that accounts are not shared, such devices may use instead a random token calculated and registered during provisioning. The random token needs to be sufficiently long, preferably being the same length as the client-side hash, e.g. 256 bits. The token may replace the client-side hashed password during verification. From a security perspective, this approach works well as long as the hashed credential is stored securely and protected from physical access attacks, and from access by other domains or applications running on the device. D. The Clipaha Library [0156] The Clipaha library is aimed at being compatible with various devices. To use the library, an exemplary Clipaha’s API may be as in Listing 1 below. [0157] Listing 1: Clipaha’s API example function handle_success (epassword) { //Make use of the encrypted password here } function handle_error (details) { //Handle error appropriately } //Replace VERSION with low, med, high or ultra Clipaha_VERSION_hash (domain, username, password, handle_success, handle_error) [0158] To avoid confusion, the database identifier has been named domain (as that is usually its content and is a reasonably safe default). The only other required parameters are the user identifier (called username for similar reasons), the password, and the success and error callbacks. The hash covers Algorithm 1 except the canonicalization (to avoid complex APIs). This API also purposefully hides the hash parameters. Doing so may avoid some of the usability issues, and make coding a user enumeration scenario more diffcult while ensuring that the code is better optimized by the compiler. D1. Proposed Security Levels [0159] Since Clipaha moves the resource usage to the client devices, developers may want to ensure that their applications are run on a large array of devices. To allow balancing security and compatibility, the library provides four security-levels with the library: low, medium, high and ultra. The specific parameters used when hashing the password with Argon2id are provided in Table 2, where iterations refer to the number of rounds the algorithm runs, and memory is the amount of memory used by the hash function. [0160] Table 2 Level low medium high ultra Iterations 6 5 3 3 Memory (MiB) 192 384 1024 2016 [0161] The security level low is intended to maximize support of very old devices, e.g. some ancient smartphones, ebook readers or even computers from the early 2000s. medium targets all computers from the mid 2000s and most smartphones and ebook readers from the last 5 years. high is the value that is recommended for new developments where only computers from the last 5 years are considered. ultra uses the maximum amount of RAM possible on our current implementation (a bit less than 2GiB because of limitations on Emscripten, the SDK used) and runs flawlessly on most modern laptops with at least 3GiB of RAM. The parameters used when hashing the password with Argon2id in the current implementation of clipaha.js are chosen to fit the memory of the device class and use as many/few iterations to keep the execution time below 20 seconds. Since higher memory requirements also involve more computation per iteration, the number of iterations needed in lower security levels is higher. [0162] Introducing security levels may represent a potential security threat. An attacker preferably targets systems using the low security level, which has lower requirements on computation and memory. Therefore, allowing a powerful offline attacker to execute credential bruteforcing at a higher rate. However, the execution time on the low security level still requires a non-trivial amount of computing time (e.g., 200 ms on a i7-7700k) compared to conventional server-side hash functions. Also, the legacy devices targeted with the low security level are expected to be phased out, increasing security requirements over time. D2. Overcoming Technical Limitations [0163] Performing password hashing in JavaScript presents various challenges. Four major challenges may be memory, multithreading, performance and data remanence. [0164] Memory-wise, most JavaScript virtual machines limit the programmer’s ability to make huge allocations. In particular, for Array-Buffers, the size is limited to 232 − 1 bytes. A paging approach may help address the limitation. On WebAssembly, work is in progress to support 64-bit addressing. On JavaScript, a paging approach helps overcome the limitation. In any case, manual testing has shown that those memory limits are actually more stringent in reality. On desktops, the limit is 2GiB for the whole memory stack (hence only 2016MiB of memory was used instead of 2048 for ultra) on both Firefox and Chrome. On mobile phones, the limits are significantly lower. For example, even when the device has more, the mobile version of Chrome limits available memory to a bit over 1GiB. In such devices, the memory requirements for high, 1GiB, or ultra, almost 2GiB, cannot be attained even when allocating memory early. [0165] Malloc may be used instead of providing a statically allocated buffer using callbacks. This is because, otherwise, the generated code may include very large memory files which are clearly undesirable. Providing the statically allocated buffer allows for disabling malloc and reduces the risk of an allocation failure caused by fragmentation. But as such issues are not observed on real systems and the only malloc allocation done is the huge buffer used by Argon2, it may be preferable to opt not to provide the statically allocated buffer. [0166] Regarding multithreading, after the discovery of the SPECTRE vulnerability, some browsers disabled the possibility of using shared memory buffers across web workers to avoid allowing their usage as a timer for exploiting side-channel attacks. In this area, the situation has improved with some browsers allowing their usage under certain specific conditions. Even in such cases, to allow threads to share memory, it is necessary to send specific headers on the web application that isolate the application and restrict the ability to add external resources. To make things worse, such exceptions are not supported widely. For example, Safari and the current ESR version of Firefox do not support shared memory across threads. In any case, to prepare for future support of threading, the number of parallelizable work units (or lanes used on Argon2) is raised up to 256 simultaneous threads. [0167] As for the processing performance, the pure JavaScript implementation is tremendously slow. The cause for the slowdown in Javascript, aside from it being usually interpreted by the browser, is that integer operations are 32-bit. Lyra2’s BlaMka hash function, the core of Argon2, makes heavy use of 64-bit multiplication, addition, rotation and bitwise operations. WebAssembly increases the performance by providing 64-bit integer support and compilation into native code and yet, presents certain performance limitations over native code. As WebAssembly becomes more widely available, single instruction, multiple data (SIMD) support and other similar improvements bring WebAssembly performance more on par. For example, preliminary testing hints that, despite still being rolled out, support for 128-bit vector SIMD provides a runtime improvement of around 20%. [0168] Native speed versus WebAssembly and JavaScript on a Core i7-4710HQ with 16 GiB of RAM is presented in Table 3, where “Factor” is normalized for the first row with native code, and Chromium version is 85.0.4183.83, while Firefox version is 68.12.0esr. [0169] Table 3 Browser Imple- low Medium high ultra i Ti F Ti F Ti F Ti F r
Figure imgf000044_0001
[0170] As can be seen in Table 3, on a Desktop, WebAssembly incurs slowdowns of around 2 to 3.5 times compared to native code while JavaScript imposes a less consistent penalty of 30 to 130 times. The WebAssembly penalty may be caused by optimization choices when compiling the middle code and by the lack of native SIMD support for the full vector length along with some minor overheads. The JavaScript one is clearly consistent with the expected impact from using an interpreted language. [0171] In relation to data remanence, it should be taken into account that JavaScript does not provide any guarantees regarding the lifetime of variables. That, mixed with the fact that strings are immutable objects, means that any approach to control the time of life of the password on the heap may be fruitless. Consequently, it is not opted for inputs or hash memory to be sanitized since doing so does not provide a significant improvement in security. E. Evaluation [0172] A test to evaluate the deployability of Clipaha was performed. Additionally, benchmarks were run on a large array of systems and devices. In doing so, not only the reliability of the system but also the impact such password hashes may have into user devices are tested. E1. Deployability Test [0173] To show the feasibility of deploying the proposed approach, a proof of concept targeting the login and registration processes was created. The code was tailored to run on an ESP8266 using MicroPython with only 80 KiB of SRAM available. The system was integrated with Clipaha by modifying the frontend code to perform the password hash. The integration and the subsequent test to verify correct and successful operation took less than an hour. [0174] Two versions of the code were benchmarked. The first uses an additional locally executed hash function, in this case SHA256, for additional security to avoid pass-the-hash attacks. The second performs a raw string comparison with a locally stored password.1000 measurements of the time it took to hash and securely compare the encrypted password on the device along with the time it took to process a login request with the local hash and make a raw comparison were performed. The hash measured for 3.7% of the time it took to perform the request with a median of 735.425 µs for the hash and 19604.25 µs for the full requests. Requests without the hash had a median of 19005.1 µs in comparison. As expected, with server relief, the code on the server side is fast even when run on a microcontroller (e.g. less than 20 ms). E2. Benchmarks [0175] The benchmarks are compared against a similar implementation using lisodium.js (that hashes the salt using Blake2 before further encryption to ensure the 16-byte fixed-size requirement of the library is met). The benchmark was successfully tested on 21 different devices and 35 setups. The benchmark was also tested on 7 devices and setups that crashed before finishing the test. [0176] A summary of the benchmarking results are shown in Table 4, where the number of failures (F), minimum (Min) and maximum (Max) seconds taken to run are presented for each security level, device type and library. Only devices with at least a success are considered. Each security level was tested 5 times per device and browser. [0177] Table 4 Library low medium high ultra
Figure imgf000045_0001
Device F Max Min F Max Min F Max Min F Max Min type 8 4 4 7 0
Figure imgf000046_0001
p . p or each system browser and library, with the median hashing time in seconds out of 5 encryptions, each with a different username and password, were compiled. Some examples are shown in Table 5. [0179] Table 5 Device Browser Library low (s) medium (s) high (s) ultra (s) Xiaomi Chrome 85.0 Clipaha 14.224 23.559 Failed Failed Redmi Note Libsodium.js 20.803 34.694 Failed Failed 8T, Snapdragon MiuiBrowser Clipaha 14.151 Failed Failed Failed 665 CPU, 4 12.4.4 Libsodium.js 21.405 Failed Failed Failed GiB RAM Opera 60.2 Clipaha 14.233 23.565 Failed Failed Libsodium.js 20.909 34.956 Failed Failed Firefox 81.0 Clipaha 9.575 15.999 25.900 54.175 Libsodium.js 17.938 29.930 48.320 100.377 Edge 45 Clipaha 7.783 12.650 20.012 41.648 Libsodium.js 12.703 21.575 34.648 69.114 Samsung Chrome 85.0 Clipaha 7.362 12.228 Failed Failed S10+, Exynos Libsodium.js 12.719 21.415 Failed Failed 9820 CPU, 8 GiB Firefox 81.0 Clipaha 7.412 12.228 Failed Failed RAM Libsodium.js 12.611 21.076 Failed Failed Fairphone 2, Chrome 85.0 Clipaha 19.134 31.571 Failed Failed Snapdragon 801 Libsodium.js 33.313 54.887 Failed Failed CPU, 2 GiB Firefox 81.0 Clipaha 18.890 31.073 Failed Failed RAM Libsodium.js 20.032 Failed Failed Failed [0180] The results of the benchmarks for Clipaha va libsodium.js on different tablets for each system browser and library, with the median hashing time in seconds out of 5 encryptions are shown in Table 6. [0181] Table 6 Device Browser Library low (s) medium (s) high (s) ultra (s) iPad, A12 Safari 14.0 Clipaha 2.279 3.739 5.940 Failed Bionic CPU, 3 GiB Libsodium.js 3.440 5.739 Failed Failed Surface Pro Chrome 85.0 Clipaha 2.015 4.048 7.689 17.674 (2017), Core Libsodium.js 4.287 7.253 11.913 25.857 i5-7300U CPU, 8 GiB RAM [0182] The results of the benchmarks for Clipaha va libsodium.js on different computers for each system browser and library, with the median hashing time in seconds out of 5 encryptions are compiled. Some examples are shown in Table 7. [0183] Table 7 Device Browser Library low (s) medium (s) high (s) ultra (s) Mac OS Chrome 91.0 Clipaha 1.126 1.873 3.328 6.124 laptop, ARM M1 CPU, Libsodium.js 1.993 3.348 5.464 11.080 8 GiB RAM Mac OS Firefox 81.0.1 Clipaha 2.792 4.370 7.546 15.717 laptop, i7- Libsodium.js 4.186 7.494 12.176 25.511 6567U CPU, 16 GiB RAM Windows 10 Edge 44.0 Clipaha 3.032 4.979 8.054 15.562 laptop, i5- Libsodium.js 6.654 11.097 18.010 34.015 7200U CPU, 8 GiB RAM [0184] Based on the full benchmark results (not shown in entirety in Tables 4-7), it may be inferred that Clipaha is 25 to 50% faster than libsodium.js. In other words, Clipaha’s approach improves by at least 50% the runtime of existing approaches and demonstrates that it can run in a resource constrained device. It is speculated that this may be caused either by additional overhead in libsodium.js or by the fact that Clipaha uses fixed Argon2 parameters which may allow the compiler to produce faster code. [0185] The data also shows that phones are up to ten times slower than computers. Such a difference may be caused by slower memory in phones, a slower processor, or worse optimization of code by the phone-based browsers. Aiming at the best intercompatibility, it can be appreciated that low, which improves on most available defaults, works on a vast majority of devices providing acceptable delays of up to 20s (which may be further reduced by caching the hashed credentials) showing that using this setting may be a reasonable decision even when considering fairly obsolete phones. Combined with caching the hashed credentials, this may also be a one-time cost amortized over a larger number of logins. Given the relatively low failure rate, medium is well suited for most modern mobile devices with 3 GiB of RAM or more where such large allocations can be performed. Finally, high and ultra are restricted to browsers like Firefox which do not limit allocation size. These two security levels also require either a high end mobile device with enough RAM or a desktop system. It should also be noted that, in a few cases, Clipaha completed the benchmarks in certain devices on which libsodium failed. This may be caused by the early allocation of memory made by Clipaha which helps avoid fragmentation. [0186] With its user friendly API and code, Clipaha has the potential to impact embedded systems, e.g. small office home office (SoHo) network appliances and IoT gateways that are resource constrained and rarely require flows more complex than registration (during provisioning) and authentication. [0187] For the client-side approach, password-based credentials (that include the password with a key known only to a specific server) may be binded to that server so only said server can recover them. This addresses the vulnerability of trusted execution environments or password managers needing to provide the unencrypted password to the program running the authentication making it possible for an attacker to obtain the password. The RedLine malware, although focused on desktop environments instead of IIoT, shows an example where such vulnerability is exploited. Essentially, without the private key the server uses to recover the password, the attacker cannot gain any relevant information about the stored password. [0188] Here, a password may be converted into a token: a piece of high entropy data that can be used for authentication but which says nothing about the password of the user it authenticates. Tokens are different from passwords in that tokens are automatically generated and are difficult for humans to remember. The mechanism is based on public key cryptography for protecting passwords stored on client devices so that an attacker, compromising only the client, cannot gain any information about the stored passwords. The attacker gains nothing from obtaining only the server’s private key as the attacker would also need the client’s token to be able to obtain the credentials and attack others. Ways may be introduced to model indistinguishability from random noise when the attacker has a dictionary containing the correct plaintext, and the model proves the security of the mechanism. [0189] Nowadays, tokens are usually implemented in one of two ways: as a shared secret (also called API key) or as a cryptographically signed authenticator. For shared secrets, the client obtains and stores a random string from the server which is then presented instead of the password for authentication. This allows removing the password altogether but introduces the additional requirement, and possible failure point, of keeping a database of which tokens are valid for which accounts. Otherwise, this introduces the same risks as passwords, where if the tokens have low entropy or are related between them, an attacker can exploit these weaknesses to try to guess them. [0190] Compared to such tokens, the approach here uses no additional database by using instead a single additional public key, and can make use of the usual authentication path once the server has decrypted the password using the public key and, optionally, verified that it is bound to the client being authenticated. [0191] The last two solutions entail the use of a function over data the attacker cannot reach. This can be performed either: by the use of a secure processor (SP), e.g. a Trusted Platform Module (TPM) or trusted execution environment (TEE) containing a cryptographic token that the server can authenticate; or by using a physically unclonable function (PUF) built into a chip. SP-based approaches’ security depends, among other things, on that which can be provided by the used SP. For example, exploits attacking weakly generated keys on TPMs or exfiltrating keys from TEEs have been found on the past. Regarding PUF-based approaches, while an attacker may not be able to clone the PUF itself, it can still make use of the one in the compromised device to impersonate it. Also, certain attacks against PUF-based approaches do exist. Various of these techniques can be combined with or without passwords to create a MFA approach. MFA approaches try to combine various techniques to gain their strengths and reduce the impact of exploitation. MFA approaches do not improve the protection of the stored passwords otherwise and do not prevent an attacker from performing offline attacks against stored passwords. Consequently, if an attacker can guess the password for another server which is not, or can not be, protected using MFA, this server may still be attacked successfully. These techniques introduce additional requirements on the user that require significantly more than just remembering the low entropy pair of username and password. This is true even for MFA. [0192] In other words, a mechanism based on public key crypography is proposed for protecting passwords stored on client devices so that an attacker compromising only the client cannot gain any information about the stored passwords. For example, extensions may be introduced to perform key rolling, client-side hashing and additional binding data. The mechanism may be implemented based on an exemplary “Box” algorithm, as denoted by Algorithm 3. [0193] Algorithm 3 – “Box” algorithm function BOXKEYGEN( ) ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ← DHGEN( ) ⊳ Create Server′s long term key return ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ end function function BOXENCRYPT( ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^) ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ^^ ^^ ← BOXKEYGEN( ) ⊳ Create one time keys ^^ℎ ^^ ^^ ^^ ← DH( ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^) ⊳ Calculate Diffie − Hellman Shared Secret ^^ℎ ^^ ← EXTRACTTHENEXPAND(( ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ^^ ^^), ^^ℎ ^^ ^^ ^^) ⊳ Extract entropy then Expand shared encryption key ( ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^) ^^ ^^ ^^ ^^ ^^ ← PAD( ^^ ^^ ^^ ^^) ⊳ Pad the data to hide its length ^^ ^^ ^^ ^^ ^^ ← AESSIVENCRYPT( ^^ℎ ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^) ⊳ Encrypt the password provided by the user PURGE( ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^, ^^ℎ ^^, ^^ ^^ ^^ ^^ ^^) ⊳ Purge the one time private key and derived keys and any other sensible data return ^^ ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ end function function BOXDECRYPT( ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^) ^^ℎ ^^ ^^ ^^ ← DH( ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ^^ ^^) ⊳ Calculate Diffie − Hellman Shared Secret ^^ℎ ^^ ← EXTRACTTHENEXPAND(( ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ^^ ^^), ^^ℎ ^^ ^^ ^^) ⊳ Extract entropy then Expand shared encryption key ( ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^) ^^ ^^ ^^ ^^ ^^ ← AESSIVDECRYPT( ^^ℎ ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^) ⊳ Decrypt the password provided by the user PURGE( ^^ℎ ^^) ⊳ Purge the derived key ^^ ^^ ^^ ^^ ← UNPAD( ^^ ^^ ^^ ^^ ^^) ⊳ Remove any padding return ^^ ^^ ^^ ^^ ⊳ May be ⊥ if decryption failed end function function SERVERPROVISIONING( ) ⊳ Executed by the server only the first time it is started ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ← BOXKEYGEN( ) ⊳ Create Server′s long term key STORE( ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ) ⊳ Store keys for later end function function CLIENTPROVISIONINGBYSERVER( ) ⊳ Executed by the server when a client is provisioned ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ← RETRIEVE( ) ⊳ Get stored key SEND( ^^, ^^ ^^ ^^ ^^ ^^) ⊳ Send the public key end function function CLIENTPROVISIONING( ) ⊳ Executed by the client when being provisioned ^^, ^^ ^^ ^^ ^^ ← QUERY( ) ⊳ Ask the username and password ^^ ^^ ^^ ^^ ^^ ← RECV( ^^) ⊳ Receive the public key ^^ ^^ ^^ ^^ ^^ , ^^ ^^ ^^ ^^ ^^ ← BOXENCRYPT( ^^ ^^ ^^ ^^ ^^, ^^, ^^ ^^ ^^ ^^) ⊳ Encrypt the password provided by the user DBSTORE(( ^^, ^^), ( ^^ ^^ ^^ ^^ ^^ , ^^ ^^ ^^ ^^ ^^)) ⊳ Store the password e.g. in the password manager (indexed by username and the identifier of the server) end function function SERVERSIDEAUTH( ) ^^, ^^ ^^ ^^ ^^ ^^ , ^^ ^^ ^^ ^^ ^^ ← RECV( ) ⊳ Receive client data ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ ← RETRIEVE( ) ⊳ Get stored keys ^^ ^^ ^^ ^^ ← BOXDECRYPT( ^^ ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^ , ^^, ^^ ^^ ^^ ^^ ^^) ⊳ Decrypt the password sent by the client ℎ ^^ ^^ ^^ ^^, ^^ℎ ^^ ^^ ^^ ^^ ← LOOKUP( ^^) ⊳ Get the stored password ℎ ^^ ^^ ^^ ^^ ← HASH(ℎ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^) ⊳ Hash (securely) the password if ^^ ^^ ^^ ^^ ≠⊥ ∧ ^^ℎ ^^ ^^ ^^ ^^ ≠⊥ ∧ ℎ ^^ ^^ ^^ ^^ = ^^ ^^ ^^ ^^ then
Figure imgf000052_0001
suceeded else SEND( ^^, ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^) ⊳ Authentication failure, mismatch end if end function function CLIENTSIDEAUTH( ) ^^ ← QUERY( ) ⊳ Ask the username ^^ ^^ ^^ ^^ ^^ , ^^ ^^ ^^ ^^ ^^ ← DBLOOKUP( ^^, ^^) ⊳ Recover stored credentials SEND( ^^, ^^, ^^ ^^ ^^ ^^ ^^ , ^^ ^^ ^^ ^^ ^^) ⊳ Send authentication data return RECV( ^^) ⊳ Get authentication status end function [0194] Algorithm 3 may be an example to carry out the method 660 of FIG.6 or may be described in similar context to the method 660 of FIG.6. [0195] The "Box" algorithm has to encrypt the password providing the following three security properties. [0196] Decryption correctness: The server can recover the encrypted data using its private key. [0197] Indistinguishability under chosen plaintext with variable length (IND-CPAL): Relevant adversaries, which are computationally bound to ^^ (where ^^ is a fundamental complexity class or the class of computational problems that are solvable in a computation time bounded by a polynomial function) and without knowledge of the server’s private key, can distinguish which of two messages of their choice was encrypted with negligible probability. This property holds even if the adversaries choose messages of different lengths. [0198] Authenticated encryption: Relevant adversaries, which are computationally bound to ^^ and tamper the encrypted data they send, can have it accepted by the server with negligible probability. [0199] A padding step may be added to ensure length obfuscation. The data is padded before encryption, consequently, the resulting construction provides indistinguishability with variable lengths. [0200] Since the client’s private key is destroyed immediately after the password is encrypted, the adversary only has knowledge of the public keys of both sides and, therefore, is unable to guess the resulting shared key. [0201] The mechanism performs credential encryption during storage on the client-side instead of the server side. Assuming a really secure communication channel, this step may be offloaded to the server in a way similar to key rolling, that will be described later on, thus avoiding any public key cryptography on the client-side. [0202] Offloading the initial encryption requires sending the plaintext password to the server over the secure channel at least once. Although this would be a valid approach if the channel was truly secure, instead, it may be preferred to ensure that the password is always sent encrypted to the server. This simplifies the protocol slightly and makes the proof more simple but, more importantly, this ensures the security of this protocol stacks on top of that of the secure channel against passive eavesdroppers following an ‘intercept now, decrypt later’ approach. Consequently, it is chosen not to offload this first encryption because the additional security against passive eavesdropers provided by never sending the plaintext password over a secure channel far may be considered to outweigh the cost of performing a one-time encryption on the client (usually during provisioning when the device is directly connected to a more powerful device). [0203] A different approach to ensure length obfuscation instead of adding padding to the password before encryption is applying a hash function to it. This approach may be described in similar context to the method 320 of FIG.3. Since the objective is extracting the password’s entropy into a fixed-size string, the hash can be any cryptographic hash function that is still secure. [0204] When prehashing the password, the server will only be able to recover the password hash instead of the original password, hence the authentication process needs to be modified to work over the hashed password instead of the plaintext password. For example, the server’s verifiers must be generated over the already hashed password. Hashing the password securely on the client-side requires changes on the authentication procedure. Consequently, although this may be a useful extension, the padding approach may be chosen to be used by default for encryption so that the length of any additional data can be hidden. [0205] It is also possible to include certain additional data along with the password in order to limit usage of the encrypted password. For example, a password may include one or more of: targeted service(s) or server(s); clients that are allowed to use the password; actions allowed or access level granted. [0206] Adding this data raises the security by explicitly limiting the scope in which passwords stored in a client may be used and by explicitly stating the targeted server, as opposed to doing so implicitly by the specific public key being used for encryption. Implementations also require additional code for validating this data when performing the password recovery step on the server or, if no validation is desired, to remove it so that only the password is provided to the authentication system. [0207] The risk of the data being modified by an attacker ought to be considered. Such risk is prevented by ensuring that the encryption cipher used in the box construct is an authenticated encryption scheme, e.g. AES-SIV. [0208] Occasionally, the server may need to change to a new public key pair, e.g. after the old private key is compromised. Key rolling may be required. For this scheme to work, the server always keeps a copy of old private keys to be able to decrypt credentials encrypted using these. [0209] Also, since the server gains access to the plaintext credentials once the client authenticates, the server also performs the same encryption steps the client would perform when storing credentials using the new public key, and sends these new encrypted credentials back to the client for storage. Further, to prevent DoS attacks, the client keeps the old ones available until it verifies the new credentials work (and maybe for a short additional period). To perform a DoS attack, an attacker that has compromised the server would instead send back random data for the client to store, thus preventing further authentication. [0210] By using public key cryptography, it is ensured that the encryption performed by the client only works in one direction. In particular, unless an attacker has access to the corresponding private key, only the server can recover the original credentials once they are encrypted. Additionally, using public key cryptography allows using the same key for all users in the same system thus preventing any kind of user enumeration issues. Even with key rolling implemented, the server only announces the last public key. After key rolling happens, the server still needs to choose the appropriate private key to decrypt the credentials sent by the client. This may usually be done using a fingerprint (e.g. the public key from the server used by the client or its hash) provided by the client but, if this is not possible, the server may attempt to use both of the private keys while blinding the computation to avoid side-channels if the first decryption succeeds. Failure to do so may allow an attacker to obtain information about the username’s presence in the database. [0211] As a consequence of the use of public key cryptography to bind the credentials to a specific server, without the corresponding private key that the server uses to decrypt the encrypted credentials, an attacker with full access to the client data cannot obtain the credentials that were originally encrypted. Such an attacker can still use the client’s data to impersonate the client against the specific server. To avoid this, techniques e.g. MFA multifactor authentication may be additionally used. [0212] Key rolling is implemented so that the client never has access to the plaintext credentials. This can be so because, after decryption, the server recovers the plaintext credentials along with any additional data embedded that it can then reencrypt and send back to the client for storage and later use. [0213] Consequently, it is expected for the protocol to protect the content of the credentials when only the server or the client are compromised. If both are compromised, the attacker can then emulate both the client and the server and use the server’s private key to decrypt the client’s bound credentials for further use. [0214] Overall, if only the client is compromised, the attacker can impersonate the client against the server but otherwise obtain no other information about the credentials; if only the server is compromised, the attacker obtains no information about the credentials from this protocol (but it may still be able to attack the verifiers used to validate the client’s credentials after decryption); if both sides are compromised, then the attacker can recover the plaintext credentials. This is still better than the status quo where an attacker can obtain the credentials just from the client data. [0215] There appears to be not much work in trying to adapt existing cryptographic security models to the particularities of passwords. A random oracle model may be used to demonstrate the security of the approach. In the model, a real game provides the attacker with the stored password and any auxiliary data the client uses to process it, including any data that the server provides to the client. An ideal game provides the attacker with random pieces of data of the same length instead. Several considerations or assumptions are made as follows: only offline adversaries are considered, adversaries able to actively or passively eavesdrop the data in transit are not considered, nor is the possibility of the adversary to test its dictionary against the online service as that should be secured by the service itself. The adversary is computationally limited and cannot run algorithms with complexity higher than ^^, and the possibility of of an attacker impersonating the actual software to trick the
Figure imgf000056_0001
into entering the password is not considered. [0216] The password oracle O modelling a dictionary with the password p may be described in Listing 2 as follows: O ^^ ^^ ^^ ^^ ( ^^, ^^) ^^( )
Figure imgf000056_0002
6: endwhile 6: shared O ^^ = ^^ + 1 7: ^^ = [ ] 7: else 8: while (| ^^| > 0) 8: ^^ ^^ =⊥ 9: ^^ ^$ ^^ 9: endif 10: APPEND( ^^, ^^) 10: return ^^ ^^ 11: ^^ ^^ ^^ ^^ ^^ ^^(s, ^^) 12: endwhile 13: shared O ^^ = ^^ 14: shared O ^^ = 0 O ^^ ^^ ^^ ^^ sets the shared variables that O will use later. The adversary does not see such shared variables, only the interface provided by O. [0217] Given an integer value ^^ ≥ 1 and a password p when first instantiated, the oracle generates a set composed of the correct plaintext password p along with other ^^ − 1 random strings, and the oracle creates a list formed from a random permutation of all the elements in the set. The resulting oracle then answers the i-th query by the adversary, returning the i-th item xi from the list. Alternatively, when the last item of the list has already been provided, the oracle returns ⊥. Consequently, when using this oracle, for each query the adversary would be able to obtain the correct password with non-negligible 1 probability Pr[ ^^ ^^ = ^^] = ^^ and a presampled random string otherwise. This models the adversary’s ability to use dictionaries and other techniques to do password guesses. The use of presampled random strings is such to ensure the attacker cannot perform statistical analysis of the returned values to distinguish the actual password from the other possible return values. [0218] ^^ = 1 is assumed to make it easier to perform and understand the proofs without affecting their validity. It is easy to reason that a proof where Pr[ ^^ ^^ = ^^] = 1 establishes [ 1 either higher or equal security as one where Pr ^^ ^^ = ^^] = ^^ (equality happening when the attacker does not gain any knowledge from knowing which of the provided ones is the right 1 password). Similarly, when Pr[ ^^ ^^ = ^^] = ^^ instead of Pr[ ^^ ^^ = ^^] = 1, the attack difficulty may be increased by up to n (if the attacker benefits from knowing the right password) as the attacker can sample the oracle until it gets all n strings and then try to perform the attack with each of them. Thus, if the system is secure when ^^ = 1, then it would also be equally or more secure when ^^ > 1. [0219] Given a value of n , it can be proven that any case where n′ ≥ n does not provide any advantage to the adversary. [0220] Let’s assume that there existed such value of n′ which provided an advantage over the case for n. The adversary would then create the set s by appending the results returned from O until ⊥ is returned. The adversary then repeatedly inserts a randomly sampled string to s until s contains n′ elements. Finally, the adversary would then choose a random permutation of s and define OA as the function returning for the i-th query the i-th element of the list. Since the resulting OA derived from O for n is functionally equivalent to the O′ for the case n′ , it is demonstrated, by construction, that there also exists an adversary for n with the same advantage. This proof does not work the other way around because if n′ < n then n′ −n < 0 making the repeat step impossible. [0221] A lower bound for the difference in advantage can be established as n grows. Let’s suppose that there is an adversary for the case n′ where n ≤ n′ . Given the oracle O′ for the case n′ , the oracle for the case n OA can be instantiated as the value returned by O′ for the first n calls followed by ⊥ for any subsequent calls. The resulting OA contains p and thus is ^^ functionally equivalent to the O for the case n with probability ^^′ since each of the n 1 elements sampled is p with probability ^^′. Consequently, the resulting adversary for n has ^^ an advantage of ^^′ of that for n′ . Since n < n′, this advantage is smaller than 1. [0222] As a consequence of these two proofs, it is demonstrated that the case where n = 1 is at worst exactly as secure as those for n′ > 1 and at best n′ times more secure than them. Hence, the abovementioned proofs for n = 1 are as secure if not more than those for any value of n greater than 1. This entails that any scheme secure against attackers knowing the password may be also secure against attackers with a longer dictionary containing the password. [0223] It is important to note that, when performing the indistinguishability games, the adversary does not have access to the actual authentication service. If the proposed adversary had access to the authentication service, it can first guess which of the strings provided by O is the actual password. Also the adversary can check if the returned encrypted password allows logging into the system. [0224] Indistinguishability will be described further as follows. [0225] A common property provided by public key cryptographic schemes is indistinguishability under chosen plaintext attack (IND-CPA). The game used for IND- CPA as defined in Listing 3 as follows: IND − CPA ^^(1 ^^, ^^) IND − CPAL ^^(1 ^^, ^^)
Figure imgf000058_0001
5: ^^ ←$ BOXENCRYPT( ^^ ^^ ^^ ^^, ^^ ^^) 5: ^^ ←$ BOXENCRYPT( ^^ ^^ ^^ ^^, ^^ ^^) 6: ^^(1 ^^ , ^^ ^^ ^^ ^^, ^^, ^^, ^^ ^^ ^^ ^^ ^^) 6:
Figure imgf000059_0001
^^(1 ^^ , ^^ ^^ ^^ ^^, ^^, ^^, ^^ ^^ ^^ ^^ ^^)
Figure imgf000059_0002
The IND-CPA is side-by-side with the IND-CPAL (indistinguishability under chosen plaintext attack with variable length) in Listing 3 above. It is noted that in IND-CPAL, the assert regarding message lengths was removed. [0226] In the game used for IND-CPA, a key pair ( ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^) is generated; then the public key, ^^ ^^ ^^ ^^, is provided to the adversary A; next, the adversary is given a polynomial amount of time to perform computations; the adversary then chooses two plaintext messages of equal length ^^0 and ^^1; the oracle samples a random bit b ←$ {0, 1} and provides the adversary with e, the encryption result of ^^ ^^. Given bA, the adversary’s guess of the value of b, the adversary’s advantage is defined as ^^ ^^ ^^ ^ ^ ^^ ^^ ^^− ^^ ^^ ^^( λ ) = [ ^^ ] 1 | ^^ ^^ ^^ = ^^ − 2|. Thus, given a security parameter λ, a protocol is considered to be secure
Figure imgf000059_0003
≤ ^^(λ). To understand the security of this approach, it is supposed that the adversary knows the stored encrypted password e′ and the value of the password p, if the adversary had a way to check if e′ is the encryption of p, it could just make ^^0= p and ^^1 ←$ {0,1}| ^^| and then win the game in the case when the oracle returned e = e′ . if the protocol is IND-CPA-secure, the adversary is not able to find if e′ is the encryption of p. [0227] When considering passwords, obfuscating the length of the inputs is important since, if disclosed, this length might help an attacker eliminate all the entries not matching that length thus disclosing information about the password. However, the above discussed definitions of indistinguishability do not provide, by themselves, a guarantee that no information can be gained about the password. To address this, the indistinguishability properties need to be proven even if the length of the encrypted messages changes. [0228] For IND-CPA, the requirement that ^^0 and ^^1have the same length may be removed to obtain IND-CPAL. It should be appreciated that IND-CPAL ⇒ IND-CPA. Still, the implication does not work the other way as algorithms may return different output lengths for different input lengths. Furthermore, most algorithms do not provide indistinguishability with variable lengths. [0229] To convert such algorithms to provide with variable lengths, the algorithms may be modified to match two requirements: first, it must always return an encrypted message of the same length independently of the length of its input; and, second, the original indistinguishability property must still hold. [0230] To ensure the encrypted message has the same length, it can be benefitted from the fact that both games do guarantee the same output length for all inputs with the same length. Hence, all the possible inputs need to ensured to be mapped into a set of strings of a fixed length and this process is called length obfuscation. [0231] A traditional approach to perform length obfuscation would be defining a maximum allowed message length (i.e., how long can the password p be at most) and then pad the input strings before processing them so that all of the possibles messages up to said length have exactly the same final length. Given the allowed set of input messages ℳ ^^1 = {0,1}(0,..., ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ), a pad function is defined as that for
Figure imgf000060_0001
^^ ^^ ^^|∃ ^^ ^^ ^^ ^^ ^^: ∀ ^^ ∈ℳ ^^1: ^^ ^^ ^^ ^^ ^^( ^^ ^^ ^^( ^^)) = ^^, i.e. that for which there exists an unpad function that can always recover the original message. Additionally the following must also hold: ^^ ^^ ^^|∀ ^^1, ^^2 ∈ℳ ^^1: | ^^ ^^ ^^( ^^1)| = | ^^ ^^ ^^( ^^2)|, i.e. the length of the result is independent of the size of the input message (for all allowed messages). [0232] For IND-CPA, this is always enough because the indistinguishability property holds for any two messages, even if they are the same, as long as they have the same length. [0233] As indicated above, the better approach, when possible, may be performing a hash of the input before passing it to the algorithm. Preferably, this may be done using a strong password hash. This can also ensure that the resulting string has always the same length without needing to limit the input size. Additionally, doing so may be more efficient since it reduces the workload the server has to perform during authentication. [0234] In this case, the indistinguishability property holds for indistinguishability under chosen plaintext attack (IND-CPA) because given the set of all possible messages of any length ℳ = {0,1}(0,...,∞) and the hash function H, then H|∀ ^^1, ^^2 ∈ ℳ: |H( ^^1 )| = |H( ^^2 )|, i.e. the length of the hash is independent of the size of the input message for all messages. Given this property, the argument becomes exactly the same as for the case with the pad function. [0235] The security of the protocol is demonstrated by using a random oracle model. The idea behind this is clear in that if an attacker cannot distinguish the real game from the ideal game with non negligible probability, then an attacker cannot distinguish the actual credentials from any other possible credentials that result from using guessed parameters with non negligible probability. [0236] This proof shows that an adversary with access only to the encrypted credentials stored in the client cannot distinguish the real from the ideal game and therefore cannot make any guesses even when knowing the password used. From this approach, it becomes fairly clear that a necessary condition to be able to recover the credentials is that one of the pieces of data the attacker has access to is derived using the targeted credentials. This is because, otherwise, since the data provided to the adversary does not contain the data to be protected, it is impossible for any adversary to tell apart the ideal game from the real game. A way to understand the reasoning behind this is to notice that both games would have the same pure function (same result for same inputs and no side effcts) the result of which being independent from the used password and therefore indistinguishable. [0237] Consequently, neither an adversary with no data nor an adversary who only has access to the private and/or public server keys can be considered to have any advantage. [0238] Similarly, it is clear that an adversary with access to both the encrypted credentials on the client, and the private key, can easily distinguish the real and the ideal game. In this case, the adversary just decrypts the credentials using the private key and see if they match the password provided by the oracle O. In the real game, the password matches, while in the ideal game, the password does not match. [0239] Exemplary applications of the oracle will be described as follow, demonstrating how the proposed approach may be used to: first, hint at the insecurity of the case where a client stores password hashes and second, show the security of Pato is the same as the security of the "Box” algorithm under indistinguishability under chosen plaintext attack with variable length (IND-CPAL). F. Insecurity Proof for Client-side Storage of Password Hashes [0240] Given a hash function H let’s assume that the client stores ℎ = H( ^^). It can be seen that an attacker with access to O can easily find the right value of p by just calling ℎ′ = H(O( )) until ℎ = ℎ′. Since this is a clearly insecure scheme, let’s see how well it fares against the definitions for IND-CPAL. [0241] For the IND-CPAL game in Listing 3 above, line 2 and all references to ^^ ^^ ^^ ^^ can be removed and line 5 can be replaced with ^^ ← ^^( ^^). In this case, A just chooses ^^0 = 0 and ^^1 ←$ ℳ repeating the choice of ^^1 until ^^( ^^0 ) ≠ ^^( ^^1 ). When called again, A returns 0 if ^^ = ^^(0) and 1 otherwise.
Figure imgf000062_0002
^^1 is already
Figure imgf000062_0001
to avoid collisions, these are not relevant, hence A will guess b
Figure imgf000062_0003
and thus always win. G. Security Proof of Pato [0242] To prove the security of Pato, its security may be reduced to that of the IND game protecting the credentials and any additional data. To do so, let’s start by modelling the adversary which can see the public data from the server and all the data from the client as follows: ^^1(1 ^^, ^^, ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^). Here, O is the oracle described above, u is the ^^ ^^ is the encrypted password, ^^ ^^ ^^ ^^ ^^ is the server’s long term public key and ^^ ^^ ^^ ^^ ^^ is the client’s temporary public key for the Diffie-Hellman exchange. For the "Box" construction, BOXENCRYPT( ^^) returns ( ^^ ^^ ^^ ^^ ^^ , ^^ ^^ ^^ ^^ ^^) while purging the private key ^^ ^^ ^^ ^^ ^^ ^^ and shared key ^^ℎ ^^ which are therefore not available to the adversary. Finally, ^^1 is defined as winning if it can return p with significant probability when ( ^^ ^^ ^^ ^^ ^^ , ^^ ^^ ^^ ^^ ^^) ←$ BOXENCRYPT( ^^) and ⊥ otherwise. [0243] Now, suppose that ^^1 exists and, in order to prove that the existence of ^^1 entails being able to break the IND game for the "Box" construction, an adversary ^^2 can be created where ^^2 is able to use ^^1 to win the experiment. [0244] For the IND-CPAL experiment defined in Listing 3 above, ^^21for the first call and ^^22 for the second would look as the one in Listing 4 as follow: IND − CPAL ^^21(1 ^^, ^^ ^^ ^^ ^^, O) IND − CPAL ^^21(1 ^^, ^^ ^^ ^^ ^^, O, ^^, ^^ ^^ ^^ ^^ ^^ )
Figure imgf000062_0005
5: return ^^1(1 ^^, O2, ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^, ^^ ^^ ^^ ^^ ^^) ≠ ^^0
Figure imgf000062_0004
[0245] This adversary is a bit more complex using a function DUP which samples all the values of O and return two instances using the resulting list that each independently behaves exactly the same as the original (and now spent) O. It then sets ^^0 to the first 1 value of the dictionary (that being p with probability ^^ ) and the second value to a random string (that is the same as BOXENCRYPT( ^^ ^^ ^^ ^^, ^^) with probability 2−|BOXENCRYPT( ^^ ^^ ^^ ^^, ^^)| when | ^^0 | = | ^^| and probability 0 otherwise. Consequently, on the
Figure imgf000063_0001
guesses 0 only if ^^1 returns our chosen ^^0. As can be seen when ^^0 is chosen and ^^0 = ^^, the adversary wins with significant 1 ^^ ^^ ^^ ( ) obability, in particular, ^^ ^ ^^ pr ^1 2 wins with probability 2 + ^^ similarly, when ^^1 is chosen, ^^2 wins as long as BOXENCRYPT( ^^ ^^ ^^ ^^,
Figure imgf000063_0002
happens with probability 1 − 2−|BOXENCRYPT( ^^ ^^ ^^ ^^, ^^)|. Thus on average, the
Figure imgf000063_0003
wins the game with non 1 −|BOXENCRYPT( ^^ ^^ ^^ ^ )| negligible
Figure imgf000063_0004
^^ ^^ ^^ ^^1 ( ^^ ) 1−2 ^, ^^ 3 ^^ ^^ ^^ ^^1 ( ^^ ) 4 + 2 ^^ + 2 = 4 + 2 ^^ − 2−|BOXENCRYPT( ^^ ^^ ^^ ^^, ^^)| 2 . Consequently, if an adversary can break Pato and guess p, the "Box" construction is not secure under IND-CPAL. [0246] As discussed above, various examples and embodiments of the invention may include the following: • A server-assisted approach may be provided to convert passwords into authentication tokens from which no password information can be derived. This tokenization happens in a way that makes using already existing infrastructure possible (the client just performs the encryption on storage while the server performs one decryption before proceeding with the usual password authentication). Additionally, knowledge of the password still suffices to authenticate. • The usefulness of the random oracle model may be introduced to prove the security of stored credentials after a compromise and a way to model off-line dictionary attacks. Then, this model may be used to provide a mathematical proof of the security of Pato. • Pato may be expanded allowing the addition of additional data to the generated tokens to be able to restrict their usage; and allowing rolling over keys after a compromise of the server’s private key. [0247] It is clear that Pato may have some limitations, e.g. it may not work along with Password Authenticated Key Exchanges (PAKEs) as doing so would require the clients to store information so that they can authenticate the server’s knowledge of the password and, therefore, allow offline attacks. Blinding approaches like those described herein may be combined with the existing (usually public key based) server-authenticating secure channel provided by the server-side to develop a hybrid key exchange approach that ensures client compromises will not disclose passwords. [0248] While the invention has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

CLAIMS 1. A method for securely manipulating a password hash, the method comprising: executing, by a client associated with a user, a SALT generation function to provide a globally unique SALT value, wherein the client is part of a client-server system; and combining, by the client, the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password of the user.
2. The method as claimed in claim 1, wherein the step of executing the SALT generation function comprises generating the globally unique SALT value comprising a globally unique system identifier of the client-server system, and optionally a username of the user.
3. The method as claimed in claim 2, wherein the step of generating the globally unique SALT value comprises delimiting the globally unique system identifier.
4. The method as claimed in claim 1, wherein the step of executing the SALT generation function comprises combining a globally unique system identifier of the client- server system with a username of the user to generate the globally unique SALT value.
5. The method as claimed in claim 4, wherein the step of combining the globally unique system identifier and the username comprises delimiting the globally unique system identifier, or the username, or both the globally unique system identifier and the username.
6. The method as claimed in claim 4 or 5, further comprising prior to executing the SALT generation function, canonicalizing the username.
7. The method as claimed in any one of claims 1 to 6, further comprising encoding, by the client, the password hash by using at least one of: compile-time hash function parameters, single-instruction-multiple-data or prefetch instructions.
8. The method as claimed as in any one of claims 2 to 7, further comprising sending, by the client to a server of the client-server system, registration information provided by the user, the password hash, and optionally the user-provided password, wherein the registration information includes the username; optionally validating, by the server, the registration information and optionally the user-provided password; and storing, in a database accessible by the server, the password hash along with the username and optionally the registration information.
9. The method as claimed in any one of claims 2 to 7, further comprising receiving, by a server of the client-server system, the password hash; hashing, by the server, the password hash by using a hashing function to obtain a server-hashed password hash; and comparing, by the server, the server-hashed password hash and a validator placed in trust of the server to obtain an indicator, wherein based on the indicator, the server associates with the user to authenticate an identity of the user.
10. The method as claimed as in claim 9, wherein the hashing function comprises a lightweight hashing function, or a keyed hashing function.
11. The method as claimed in claim 9 or 10, further comprising performing multi-factor authentication to provide an additional proof of the identity of the user, or a password authenticated key exchange to verify the password hash to mutually authenticate the client and the server, or a hybrid exchange to authenticate the client by verifying the client’s knowledge of the user-provided password, and the server by using a way other than the server’s knowledge of the user-provided password.
12. The method as claimed in any one of claims 9 to 11, further comprising combining, by the client, the globally unique SALT value with the password hashing function to generate and provide a replacement password hash of a replacement user-provided password; additionally receiving, by the server, the replacement password hash; optionally receiving, by the server, the replacement user-provided password, or the user-provided password, or the username; and upon successfully authentication of the identity of the user, storing, in a database accessible by the server, the replacement password hash in place of the password hash stored in the database.
13. The method as claimed as in any one of claims 1 to 12, further comprising caching, by the client, the password hash.
14. One or more non-transitory computer readable storage media each having stored thereon at least part of a processor-executable software instruction set, wherein the processor-executable software instruction set is configured to cause one or more processors to execute a method for securely manipulating a password hash as claimed in any one of claims 1 to 13.
15. A client-server system comprising: a client configured to execute a SALT generation function to provide a globally unique SALT value and combine the globally unique SALT value with a password hashing function to generate and provide the password hash of a user-provided password of a user, wherein the client is associated with the user; and a server configured to receive the password hash from the client.
16. The client-server system as claimed in claim 15, wherein the client is further configured to generate the globally unique SALT value comprising a globally unique system identifier of the client-server system, and optionally a username of the user.
17. The client-server system as claimed in claim 15, wherein the client is further configured to combine a globally unique system identifier of the client-server system with a username of the user to generate the globally unique SALT value.
18. The client-server system as claimed in claim 16 or 17, wherein the client is further configured to perform at least one of: canonicalizing the username; or delimiting the globally unique system identifier; or delimiting the username.
19. The client-server system as claimed as in any one of claims 16 to 18, wherein the server is further configured to: receive, from the client, registration information provided by the user, the password hash, and optionally the user-provided password, wherein the registration information includes the username; optionally validate the registration information and optionally the user-provided password; and store, in a database accessible by the server, the password hash along with the username and optionally the registration information.
20. The client-server system as claimed as in any one of claims 16 to 18, wherein the server is further configured to: hash the password hash by using a hashing function to obtain a server-hashed password hash; and compare the server-hashed password hash and a validator placed in trust of the server to obtain an indicator, wherein based on the indicator, the server associates with the user to authenticate an identity of the user.
21. The client-server system as claimed as in claim 20, wherein the client is further configured to combine the globally unique SALT value with the password hashing function to generate and provide a replacement password hash of a replacement user-provided password, and wherein the server is further configured to: additionally receive, from the client, the replacement password hash; optionally receive, from the client, the replacement user-provided password, or the user-provided password, or the username; and upon successfully authentication of the identity of the user, store, in a database accessible by the server, the replacement password hash in place of the password hash stored in the database.
22. The client-server system as claimed in any one of claims 15 to 21, wherein the client is further configured to perform at least one of: encoding the password hash by using at least one of: compile-time hash function parameters, single-instruction-multiple-data or prefetch instructions; or caching the password hash.
23. A method for securing a user-provided password in a client for recovery only by an authentication server, the method comprising: providing, by the client, a password hash obtained from a method as claimed in any one of claims 1 to 4 or by using a lightweight hash of the user-provided password; generating and storing, by a server, a public key and a private key; receiving, from the server by the client, the public key; encrypting, by the client, the password hash based on the public key to obtain an encrypted password hash; storing, by the client, the encrypted password hash in a storage medium, wherein the encrypted password hash is optionally associated with a username of a user and an identifier of the server; receiving, from the client by the server, the encrypted password hash and optionally the username; and authenticating the client as the user by the authentication server, wherein authenticating the client comprises decrypting the encrypted password hash using the stored private key; optionally hashing the decrypted password hash using a hashing function; and determining that the decrypted password hash or the optionally hashed decrypted password hash is the same as a value associated with the password hash previously stored in a database accessible by the server.
24. The method as claimed as in claim 23, wherein the step of providing, by the client, the password hash comprises: obtaining, by the client, the username of the user and the user-provided password; hashing, by the client, the user-provided password using the method as claimed in any one of claims 1 to 4 to obtain the password hash; and storing the value associated with the password hash in the database.
25. The method as claimed as in claim 23 or 24, wherein the hashing function comprises a lightweight hashing function, or a keyed hashing function.
26. A method for securing a user-provided password in a client for recovery only by an authentication server, the method comprising: providing a registration process, wherein the registration process comprises obtaining, by the client, the user-provided password of a user and optionally a username of the user; and associating a value with the user-provided password; providing a setup process, wherein the setup process comprises generating and storing, by a server, a public key and a corresponding private key; providing a provisioning process, wherein the provisioning process comprises receiving, from the server by the client, the public key; encrypting, by the client, the user-provided password based on the public key to obtain an encrypted password value; and storing, by the client, the encrypted password value in a storage medium, wherein the encrypted password value is associated with the username and an identifier of the server; and providing an authentication process to authenticate the client by the authentication server, wherein the authentication process comprises retrieving, by the client, the stored encrypted password value; receiving, from the client by the server, the retrieved encrypted password value and optionally the username; decrypting the retrieved encrypted password value using the stored corresponding private key to obtain a decrypted value; and determining that the decrypted value is the same as the value associated with the user-provided password.
27. The method as claimed in claim 26, wherein the provisioning process further comprises prior to the step of encrypting the user-provided password, obtaining the user- provided password and optionally the username, by the client, if the user-provided password and optionally the username are not stored during the registration process; and associating the value with the user-provided password obtained during the provisioning process.
28. The method as claimed in claim 26 or 27, wherein the step of associating a value with the user-provided password during the registration process further comprises transforming, by the client, the user-provided password; receiving, from the client by the server, the transformed user-provided password; transforming, by the server, the transformed user-provided password to obtain a first transformed value; and storing, by the server, the first transformed value; wherein the step of encrypting the user-provided password during the provisioning process comprises encrypting, by the client, the transformed user-provided password based on the public key to obtain the encrypted password value; wherein after the step of retrieving the stored encrypted password value, the authentication process further comprises transforming, by the client, the retrieved encrypted password value to obtain a transformed retrieved value; receiving, from the client by the server, the transformed retrieved value and optionally the username; transforming, by the server, the transformed retrieved value to obtain a server-transformed value; wherein the step of decrypting the retrieved encrypted password value during the authentication process comprises decrypting the server-transformed value using the stored corresponding private key to obtain the decrypted value; wherein after decrypting the server-transformed value, the authentication process further comprises transforming, by the server, the decrypted value to obtain a second transformed value; retrieving, by the server, the stored first transformed value; transforming, by the server, the stored first transformed value to obtain a third transformed value; and wherein the step of determining during the authentication process comprises determining that the second transformed value is the same as the third transformed value.
29. The method as claimed in claim 28, wherein the step of encrypting the transformed user-provided password during the provisioning process comprises transforming, by the client, the user-provided password to obtain a provisioning transformed user-provided password value; and encrypting, by the client, the provisioning transformed user-provided password value based on the public key to obtain the encrypted password value.
30. The method as claimed in claim 29, wherein encrypting the transformed user- provided password or encrypting the provisioning transformed user-provided password value comprises: padding the transformed user-provided password or the provisioning transformed user-provided password value; and encrypting the padded transformed user-provided password or the padded provisioning transformed user-provided password value using public key encryption to obtain the encrypted password value.
31. The method as claimed in claim 30, wherein decrypting the server-transformed value further comprises: unpadding the decrypted value.
PCT/EP2023/078546 2022-10-14 2023-10-13 Method for securely manipulating a password hash, a client-server system involving the same, and methods for securing a user-provided password in a client for recovery only by an authentication server WO2024079340A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10202251389F 2022-10-14
SG10202251389F 2022-10-14

Publications (1)

Publication Number Publication Date
WO2024079340A1 true WO2024079340A1 (en) 2024-04-18

Family

ID=88417122

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/078546 WO2024079340A1 (en) 2022-10-14 2023-10-13 Method for securely manipulating a password hash, a client-server system involving the same, and methods for securing a user-provided password in a client for recovery only by an authentication server

Country Status (2)

Country Link
TW (1) TW202420776A (en)
WO (1) WO2024079340A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118233095A (en) * 2024-04-28 2024-06-21 上海煜安华信息安全技术有限公司 Sensitive information protection method and system
CN118378303A (en) * 2024-06-25 2024-07-23 西南石油大学 Database security management method and system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6834112B1 (en) * 2000-04-21 2004-12-21 Intel Corporation Secure distribution of private keys to multiple clients
WO2008053279A1 (en) * 2006-11-01 2008-05-08 Danske Bank A/S Logging on a user device to a server
US20090307495A1 (en) * 2008-06-04 2009-12-10 Panasonic Corporation Confidential communication method
US20110131415A1 (en) * 2009-11-30 2011-06-02 James Paul Schneider Multifactor username based authentication
US20200329038A1 (en) * 2018-05-23 2020-10-15 Verum Securitas, Inc. Personalized security system
US11321448B1 (en) * 2017-06-20 2022-05-03 State Farm Mutual Automobile Insurance Company System and method for improving the security of stored passwords for an organization

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6834112B1 (en) * 2000-04-21 2004-12-21 Intel Corporation Secure distribution of private keys to multiple clients
WO2008053279A1 (en) * 2006-11-01 2008-05-08 Danske Bank A/S Logging on a user device to a server
US20090307495A1 (en) * 2008-06-04 2009-12-10 Panasonic Corporation Confidential communication method
US20110131415A1 (en) * 2009-11-30 2011-06-02 James Paul Schneider Multifactor username based authentication
US11321448B1 (en) * 2017-06-20 2022-05-03 State Farm Mutual Automobile Insurance Company System and method for improving the security of stored passwords for an organization
US20200329038A1 (en) * 2018-05-23 2020-10-15 Verum Securitas, Inc. Personalized security system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118233095A (en) * 2024-04-28 2024-06-21 上海煜安华信息安全技术有限公司 Sensitive information protection method and system
CN118378303A (en) * 2024-06-25 2024-07-23 西南石油大学 Database security management method and system

Also Published As

Publication number Publication date
TW202420776A (en) 2024-05-16

Similar Documents

Publication Publication Date Title
US10484365B2 (en) Space-time separated and jointly evolving relationship-based network access and data protection system
Das et al. An improved and effective secure password-based authentication and key agreement scheme using smart cards for the telecare medicine information system
US20060265446A1 (en) Dynamic executable
Wang et al. EIDM: A ethereum-based cloud user identity management protocol
WO2024079340A1 (en) Method for securely manipulating a password hash, a client-server system involving the same, and methods for securing a user-provided password in a client for recovery only by an authentication server
US20200228311A1 (en) Lightweight encryption, authentication, and verification of data moving to and from intelligent devices
Li et al. Towards smart card based mutual authentication schemes in cloud computing
Schläpfer et al. Security on IoT devices with secure elements
US11861182B2 (en) Integrated circuit device with an authentication module
Lounis et al. D2D-MAP: A drone to drone authentication protocol using physical unclonable functions
Prabakaran et al. Secure channel for financial transactions in cloud environment using blockchain technology
Birnstill et al. Introducing remote attestation and hardware-based cryptography to OPC UA
Diomedous et al. Practical password hardening based on TLS
Gao et al. Low cost RFID security protocol based on rabin symmetric encryption algorithm
Zhang et al. Strong Authentication without Temper-Resistant Hardware and Application to Federated Identities.
Hatzivasilis et al. Lightweight password hashing scheme for embedded systems
Akram et al. Remote attestation mechanism for user centric smart cards using pseudorandom number generators
Vanhoef et al. A Security Analysis of WPA3-PK: Implementation and Precomputation Attacks
Wang et al. Efficient Bitcoin Password-protected Wallet Scheme with Key-dependent Message Security.
Pavani A Novel Authentication Mechanism to Prevent Unauthorized Service Access for Mobile Device in Distributed Network
Malipatlolla et al. A novel architecture for a secure update of cryptographic engines on trusted platform module
Liu et al. A portable blind cloud storage scheme against compromised servers
Riera et al. Clipaha: A Scheme to Perform Password Stretching on the Client
Shriny et al. Design and implementation of the protocol for secure software-based remote attestation in IoT devices
Barbosa et al. Rogue key and impersonation attacks on FIDO2: From theory to practice

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23790288

Country of ref document: EP

Kind code of ref document: A1