March 18, 2023: The preprint has been updated to add a patent disclosure.
This post is an extended abstract of a paper to be presented at HCI International 2023. A preprint of the full paper is available here.
Two-factor authentication (2FA) to a web application (hereinafter, the “relying party, or RP”), where the first factor is a password and the second factor is a security code sent to the user by the RP, has been touted as a solution to the vulnerabilities of passwords. But traditional 2FA is now known to be vulnerable to phishing attacks, as the security code can be relayed by a man-in-the-middle attacker in the same way as the password. On the other hand, cryptographic authentication with a key pair credential is phishing resistant because the private key is not transmitted to the attacker. Widespread adoption of cryptographic authentication could greatly improve the security of web applications, and cybersecurity more generally.
But as is the case for any new technology, adoption of cryptographic authentication will require a favorable user experience (UX), and current experiences face well-known challenges. In this paper we propose alternative user experiences that overcome these challenges in two different ways.
Issues that complicate the UX of cryptographic authentication
At first glance, cryptographic authentication with a key pair supports a very simple user experience: the frontend of the RP registers the public key with the backend, and later logs in without user interaction by proving possession of the private key. But the private key must be stored in some hardware, and two issues complicate the UX: (i) how to make that hardware accessible to the various browsers in various devices that the user may want to use, and (ii) how to prevent impersonation by an attacker who captures or controls that hardware.
FIDO2/WebAuthn
A FIDO authenticator is a cryptographic module that can generate a key pair, known as a FIDO credential, and prove possession of the private key by signing a challenge. The World Wide Web Consortium (W3C) has published an interface to the latest generation of FIDO authenticators as a Web API, known as WebAuthn. The FIDO Alliance uses the term FIDO2 to refer to the WebAuthn specification and the authenticators that support it. Platform providers including Microsoft, Apple and Google have now embedded FIDO2 authenticators in their platforms, making FIDO technology generally available on the web.
Platform authenticators address the second complicating issue mentioned above: they prevent exfiltration of the private key by malware, provide tamper resistance to prevent physical extraction of the key by an attacker who captures the device, and require unlocking of the authenticator before use. The unlocking procedure is the same one that is used for unlocking the device after a period of inactivity: usually the user supplies a biometric, and if that fails a pin or password, which must be simple since it may have to be entered repeatedly. But platform authenticators do not address the first complicating issue. The authenticator is only accessible to browsers running in one device, and this has been blamed for lack of adoption. A white paper published by the FIDO Alliance has reported that FIDO2/WebAuthn “has not attained large-scale adoption in the consumer space,&rdquop and has attributed this to UX challenges that consumers face with platform authenticators: “having to re-enroll each new device”, and having “no easy ways to recover from a lost or stolen device”.
Multi-device FIDO credentials (“passkeys”)
As anticipated in the white paper, Apple, Google and Microsoft are trying to make it easier to recover from a lost or stolen device by syncing FIDO credentials across authenticators in devices with operating systems from the same platform provider. A synced credential is called a “passkey”, presumably because, like a password, it can be used on multiple devices.
But syncing faces multiple challenges. It breaches a tenet of cryptography, viz., that a private key generated in a cryptographic module never leaves the module in the clear; the white paper suggests mitigating this breach with a complex scheme that combines single-device and multi-device credentials, which, if ever implemented, will complicate the UX. While a new device doesn't have to be enrolled with RPs, it must be enrolled with the platform provider for syncing, which may be just as onerous. Enrollment for syncing requires user authentication to the platform provider with traditional password-based phishing-vulnerable 2FA (see “Synchronization security” in Apple's About the security of passkeys), discouraging adoption by contradicting the marketing message that FIDO credentials are passwordless and phishing resistant. And credentials cannot be synced between devices with different operating systems.
Proposed UX: multi-device authentication with on-the-fly device enrollment
The loss of credential problem is not unique to cryptographic authentication. It occurs when a user forgets a password, and it has a standard phishing resistant solution in the consumer space: an email message is sent to a registered address with a password reset link containing an address verification code. (Manually entering the code would be phishing-vulnerable but clicking on the link is not.) This solution can be adapted as follows to construct a user experience where the user can log in with any browser on any platform without prior enrollment of the device with the relying party or the platform provider.
After registering on an initial browser in an initial device, the user has the private key component of a FIDO credential in the platform authenticator of the device, and a credential ID in browser storage. To log in, the user enters the email address on the login form. If there is credential ID in the browser, the identified FIDO credential in the authenticator signs a random challenge generated by the RP. If not, the RP sends an email verification message with a link containing a self-attestation challenge (intended for key confirmation) in addition to the verification code. The user opens the link in the browser, causing a new FIDO credential to be created on-the-fly in the platform authenticator and a credential ID for the new credential to be stored in the browser, and logging the user in. (Notice that different browsers in the same device create different credentials in the platform authenticator of the device.) This results in the following user experience:
REGISTRATION
1. User enters email address and user data on initial browser and clicks "Register"
2. An email verification message is sent containing a link
3. User opens link in initial browser
4. User supplies biometric, PIN or simple password to unlock authenticator
=> FIDO credential is created in authenticator
=> Credential ID is stored in initial browser
=> User is now registered, and logged in on initial browser
LOGIN ON BROWSER HAVING A CREDENTIAL ID
1. User enters email address in login box and clicks "Log in"
2. User supplies biometric, PIN or simple password to unlock authenticator
=> User is logged in on browser
LOGIN ON BROWSER NOT HAVING A CREDENTIAL ID
1. User enters email address in login form and clicks "Log in"
2. An email verification message is sent containing a link
3. User opens link in browser
4. User supplies biometric, PIN or simple password to unlock authenticator
=> FIDO credential is created in authenticator
=> Credential ID is stored in browser
=> User is logged in on browser
An illustration of this user experience with key pairs kept in browser storage can be found in a GitHub demo.
Proposed UX: multi-device authentication with a cryptographically protected strong password
The above on-the-fly-enrollment UX uses unmodified authenticators and FIDO credentials. This UX, on the other hand, uses a credential augmented with a secret salt, and an enhanced authenticator.
FIDO is advertised as providing two-factor authentication based on the fact that a knowledge factor may be required to unlock the authenticator. But the second factor is only a PIN or a simple password, not considered to be a true password since FIDO authentication is advertised as passwordless. The following UX, on the other hand, combines the cryptographic credential with a full-fledged strong password. The combination is phishing resistant because the private key is not transmitted to the RP. Furthermore, the combination protects the password against reuse, and both the password and the public key against a breach of the RP's credential database. (The public key is protected against any cryptographic weakness of the signature cryptosystem, and against a postquantum attacker who breaches the database.) To achieve this, the enhanced authenticator hashes the password with the secret salt, the RP further hashes it with the public key, and only the final hash is stored in the database.
As in the above on-the-fly-enrollment UX, the user logs in with an email address on any browser in any device, and a message with an address verification link is sent if the there is no credential ID in the browser. But the password can only be verified if it is always hashed with the same secret salt and the same public key. Therefore, all browsers in all devices must use the same credential, or, in other words, the augmented credential must be an augmented passkey. This is achieved, without syncing, by providing the enhanced authenticator with a pseudo-random bit generation seed to be used for regenerating the augmented passkey. The seed is derived by the RP in a hardware security module (HSM) from random bits and the email address, and included in the link along with the address verification code and the self-attestation challenge.
This results in the following UX:
REGISTRATION
1. User enters email address and user data on initial browser and clicks "Continue"
2. An email verification message is sent containing a link
3. User opens link in initial browser
=> Augmented passkey credential is regenerated in authenticator
=> Credential ID is stored in initial browser
4. A password registration form is presented
5. User enters and confirms password
=> User is now registered, and logged in on initial browser
LOGIN ON BROWSER HAVING A CREDENTIAL ID
1. User enters email address in login form and clicks "Continue"
2. A password entry form is presented
3. User enters password
4. If password is correct, user is logged in on browser
LOGIN ON BROWSER NOT HAVING A CREDENTIAL ID
1. User enters email address in login form and clicks "Continue"
2. An email verification message is sent containing a link
3. User opens link on browser
=> Augmented passkey credential is regenerated in authenticator
=> Credential ID is stored in browser
4. A password entry form is presented
5. User enters password
6. If password is correct, user is logged in on browser