I have just published a GitHub repository demonstrating a method of two-factor cryptographic authentication with a fusion credential, which provides the same user experience as traditional authentication with username and password, but with strong security. Developers with an Amazon AWS account can use a script provided in the repository to install the demo on an EC2 instance of their own. A live demo running on a Pomcor server is also available at demo.pomcor.com.
Security benefits of credential fusion
By analogy with biometric fusion, where two biometric modalities are combined in a manner that provides higher accuracy than if they were used separately, credential fusion combines authentication factors in a manner that provides stronger security than if they where used independently of each other.
In the demo, a password is fused with a cryptographic credential comprising a key pair extended with a secret salt. To authenticate, the frontend of the relying party (RP) hashes the user’s password with the secret salt, signs a challenge with the private key, and sends the public key, the signature, and the salted password to the backend. The backend verifies the signature with the public key, then computes a hash of the salted password with the public key, called the fusion hash, and verifies it against a registered version of that hash. The public key and the secret salt are deleted after authentication, and only the fusion hash is stored in the backend.
If the password and the extended key pair were used separately, the password would provide protection against device theft and the key pair would provide protection against a man-in-the-middle (MITM) phishing attack where the phishing site would relay messages between the legitimate site and the user’s browser and capture the session cookie after the user logs in. This would be prevented because the frontend of the phishing site would not have access to the private key, which is protected by the same origin policy of the web enforced by the browser. But the password would be still be vulnerable to phishing attacks, reuse at malicious sites, and backend breaches.
In the fusion credential, on the other hand, the password and the cryptographic credential protect each other as follows:
- The password is protected against capture by a phishing site, because it is not sent in the clear.
- The password is protected against reuse at malicious sites that use traditional authentication by username and password because the password is not sent in the clear, and at malicious sites that use a fusion credential as in the present authentication method, because different such sites would use different secret salts.
- The password is protected against backend breaches because neither the password nor any value derived from the password that could be used in a dictionary attack are stored in the backend. In traditional authentication with username and password, by contrast, a salted password is stored in the password database, along with the salt itself. The salt prevents dictionary entries being tried against all salted passwords at once, but does not prevent dictionary entries being tried against the salted passwords one at a time. In the present authentication method the password is hashed with a salt, but like the private key, the salt is a secret that never leaves the user’s browser, and neither the salted password nor the salt are stored in the backend.
- The key pair is protected against cryptanalytic and postquantum attacks, because the public key is not stored in the backend. In traditional cryptograhic authentication with a key pair, the public key is registered with the RP and stored in the backend database. An attacker who breaches the backend might be able to derive the private key from the public key, either by exploiting a weakness of the signature cryptosystem, or, in a perhaps not so distant future, by using a quantum computer. But in the present authentication method, only the fusion hash is stored in the backend.
Storage of the cryptographic credential
In the demonstration, the extended key pair is stored in the browser’s localStorage facility. In a paper presented at HCI International 2023 (which did not yet used the “fusion” terminology) I explained how it could be stored in a modified FIDO authenticator, where it would be protected against exfiltration by malware. FIDO authenticators store key pairs, which the FIDO Alliance calls “FIDO credentials” (or “passkeys” when synchronized across platform authenticators implemented by the same OS vendor), and provide a second factor by requiring the user to unlock a FIDO credential before use, with the same PIN or biometric that is used to unlock the device. This kind of second factor would not be necessary if the cryptographic credential of this demo were stored in an authenticator, since a second factor, stronger than a PIN or a biometric with fallback to a PIN, would be provided by the fused password.
Your user experience in the demonstration
The demonstration features a simple web site with three public pages and three private pages. Public Page 1 is the home page. You have to log in before navigating to a private page.
There is a link to a registration page on every public page. To create an account you visit the registration page on your browser and enter your email address. A message with an email verification link is then sent to that address. If you click on the link in your browser a cryptographic credential for your email address is installed in that browser and explicitly associated with your email address in the browser storage facility. You are then asked to choose a password. After you enter and confirm the password, your web site registration is completed and you are logged in on your browser.
There is a login form at the top of every public page, and in a login page where you are redirected if you try to navigate to a private page without being logged in. To log in on any browser (in any device), you enter your email address on a login form. The RP frontend checks if there is a cryptographic credential associated with that email address in browser storage. If so, you are prompted for your password and you are logged in if the password you enter is correct. On the other hand, if you are using a new browser where no cryptographic credential associated with your email address can be found in browser storage, a message with an email verification link is sent to the address. If you click on the link in the new browser, a cryptographic credential for your email address is installed in that browser, you are asked to enter your password, and you are logged in if the password you enter is correct.
Credential replication without synchronization
In one-factor cryptographic authentication, it is possible to generate a random key pair in each browser, and associate the public key components of all those key pairs with the same user record in the backend. I have published two demonstrations of one-factor cryptographic authentication with such key pairs, one that stores the user records and public keys in an sql backend, and another one that stores them in a nosql backend.
But in the two-factor authentication method of the present demonstration, the same cryptographic credential must be used in all browsers, because the same password must be used in all browsers. This is achieved, without synchronization, by:
- Deriving a seed for the generation of pseudo-random bits from the email address and a master secret, and
- Using pseudo-random bits derived from that seed in the generation of the cryptographic credential, upon email address verification.
The demonstration allows the master secret to be rotated to allow a user whose cryptographic credential has been compromised to generate a different cryptographic credential from the same email address, without affecting the cryptographic credentials of other uses.
In the HCII paper, and in an earlier blog post, I said that the seed was to be sent along with the email verification code. This is not necessary, however, and is not a good idea, since the seed would then be exposed to capture for an indefinite period of time if the user saved the email verification message. In the demonstration, the seed is computed by the RP backend from the email address and the master secret when the user clicks on the email verification link, both during registration and when authenticating on a new browser.