Cryptographic authentication identifies a user by proof of possession of the private key component of a cryptographic credential. In authentication with a two-party (2P) credential, the associated public key is registered with the relying party. In authentication with at three-party (3P) credential, it is included in a certificate signed by a third party, which binds it to attributes that identify the user to the relying party. Examples of such certificates include TLS client certificates, credit-card certificates, and rich credentials.
Here we are concerned with 2P cryptographic authentication to a web site or web application.
On the web, a 2P cryptographic credential can be stored in a FIDO authenticator accessed through the WebAuthn API, or in browser storage such as the localStorage facility accessed through the Web Storage API or an IndexedDB database accessed through the IndexedDB API. FIDO authenticators are now generally available on the web because all platforms (Windows computers, Mac computers, iPhones and Android phones) now include platform authenticators, which all browsers make available to the JavaScript frontends of relying parties. The use of browser storage to store a 2P credential is demonstrated in two demo apps that we have published on GitHub, one of them with a MongoDB backend, the other with a MySQL backend. The apps use the Pomcor JavaScript Cryptographic Library (PJCL), now available in a GitHub repository, for both client-side and server-side cryptography.
Even though platform authenticators have become generally available, a FIDO Alliance white paper has reported that FIDO2 authentication has not attained large-scale adoption in the consumer space, and attributed the lack of adoption to challenges faced by consumers when a credential is lost because the device containing the platform authenticator becomes unavailable. This loss-of-credential problem is inherent to cryptographic authentication and also affects authentication with a key pair stored in the browser, which becomes unavailable if the user switches to a different browser. But browser storage and authenticator storage lend themselves to different solutions to the problem, with different user experiences and different authentication postures.
We have explored this complex topic in a four-part series of blog posts:
- Part 1: Passwordless Authentication for the Consumer Space. The FIDO Alliance white paper describes a FIDO solution to the loss-of-credential problem that is being implemented by Apple, Google and Microsoft, where multi-device credentials are synced across platform authenticators. This post describes a browser-storage solution, where the user logs in on a new browser with an email address and receives a link that creates a single-browser credential when opened in that browser.
- Part 2: Comparative Security Analysis of Three Cryptographic Authentication Solutions for the Web. This post compares the security postures of FIDO2 authentication as it exists today, FIDO2 authentication with multi-device credentials as they are being implemented according to the white paper, and authentication with single-browser credentials stored in each browser as described in Part 1.
- Part 3: Strong Authentication for the Consumer Space. Cryptographic authentication as described in parts 1 and 2 is a one-factor authentication method, with an inherent vulnerability to theft of the device containing the credential, mitigated to a greater or lesser extent by requiring a PIN or a biometric to unlock the authenticator or screen-unlock the device containing the credential. This post describes a combination of the cryptographic credential with a password, which eliminates the vulnerability and provides strong protection for the password, and against any weakness that might be discovered in the signature scheme used to compute the signature that proves possession of the private key.
- Part 4: A User Experience for Strong Authentication in the Consumer Space. This post describes a kind of attack against which consumers need and want passwords. It argues for authentication with a password-centric two-factor user experience, but shows that the method of part 1 for logging in on multiple browsers by generating a different cryptographic credential on each browser does not work when the cryptographic credential is combined with a password as described in part 3. It proposes instead to generate the same credential on all browsers by seeding a deterministic random bit generator with bits derived from the user’s email address and random bits stored in a hardware security module.