This is part 1 of a series on cryptographic authentication. Part 2 and Part 3 are now available.
FIDO adoption lags in spite of general availability
In a white paper issued in March 2022 the FIDO Alliance candidly announced that FIDO-based authentication based on the FIDO2 standards, which include the Client-To-Authenticator Protocol of the FIDO Alliance and the companion Web Authentication API (WebAuthn) of the W3C “has not attained large-scale adoption in the consumer space”.
FIDO2 is a cryptographic authentication solution for the web, which uses a key pair managed by an authenticator and is advertised by the FIDO Alliance as being “passwordless”. The key pair may be stored in the authenticator, or, equivalently from a security viewpoint, it may be encrypted under a symmetric key stored in the authenticator, and exported to play the role of a “credential ID”. The authenticator may be a “roaming authenticator” carried in a “security key”, or a “platform authenticator” provided by the OS of the user’s smartphone or laptop.
Early authenticators were security keys, which few web users had. Today most smartphones and laptops have platform authenticators, and that makes FIDO2 a generally available web technology. But the announcement by the FIDO Alliance shows that general availability has not translated into general adoption.
The white paper attributes this to 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” as the credentials managed by the platform authenticator of the device are lost. To address the loss-of-credential problem, Apple, Google and Microsoft have announced a joint effort to devise solutions that are expected to become available “in the course of the coming year” and that, according to the white paper, will involve “multi-device credentials”.
Another contributing factor to the lack of adoption, however, is no doubt the complexity and cost of the FIDO2 authentication solution. Implementing the solution in a web app requires FIDO Server software provided by a company certified to provide such software by the FIDO Alliance. A team from the certified company must work with a team from the company that is developing the app to integrate the solution into the app. By contrast, an ordinary 2FA solution is implemented by the app developers themselves, possibly by a single developer, without any integration effort.
Thus FIDO faces two obstacles to widespread adoption: usability and cost.
Two working demonstrations of cryptographic authentication on GitHub
But cryptographic authentication need not be complicated, costly
or challenging to the consumer. It can be implemented simply by
storing a key pair in persistent browser storage (localStorage or
IndexDB), registering the public key, and authenticating by proof of
possession of the private key. I will refer to this as the browser
storage solution to cryptographic authentication while referring
to the use of a FIDO authenticator as the FIDO solution, or
the authenticator storage solution, glossing over the fact that
the private key may be exported under encryption rather than
physically kept in the authenticator.
The browser storage solution can easily overcome the two obstacles
that FIDO faces in the consumer space. To demonstrate this I have
published on GitHub two demo web apps that implement passwordless,
phishing-resistant cryptographic authentication with a key pair
credential, without relying on an authenticator. In both of them
the key pair is generated in the browser by the JavaScript frontend
of the app, and kept in the localStorage facility
provided by the
Web Storage
API. One
of them uses a “nosql” (MongoDB) backend database to
register the public key and store the user data,
while the
other uses an “sql” database for that purpose.
Both use a Node.js web server on the backend, and the Pomcor JavaScript Cryptographic Library (PJCL) for both frontend and backend cryptography. The use of Node.js and PJCL, however, is just a matter of convenience, motivated by the fact that PJCL has been refactored as an ES6 module and is now available on GitHub and on npm. On the backend I could have used, for example, Apache and OpenSSL and on the front end I could have used a JavaScript cryptographic library such as, for example, the Stanford JavaScript Cryptographic Library (SJCL) instead of PJCL.
The GitHub repository for each app includes a bash script that can be used to install the app and its dependencies after the repository has been cloned to a free-tier EC2 Linux server in the Amazon AWS cloud.
The apps demonstrate that the browser storage solution can overcome the cost obstacle faced by FIDO in the consumer space because either one can be implemented in a few weeks by a single developer; and they demonstrate that it overcomes the usability obstacle by providing the user experience described below.
A user experience that solves the loss-of-credential problem
Both demo apps implement the following user experience (UX):
- To create an account, the user enters user data on a registration form, including her email address and personal data exemplified in the apps by her first and last names. This causes the app to create a user record containing the user data. No key pair is created yet.
- The app sends the user a message to the registered address, containing a link that has the dual purpose of verifying the email address and creating the key pair credential.
- The user opens the link in a browser, causing a credential to be created in that browser for that user, identified by her email address; a login session is also created in the browser for the user, implemented in the usual way by a session cookie referring to a session record in the backend database. The credential is created by the JavaScript frontend of the app, which generates the key pair, stores it in the browser, and registers the public key with the backend. The backend does NOT store the public key in a field of the user record; instead, it creates a separate credential record comprising the public key and the email address, which is used as a reference to the user record. This allows multiple credentials to be registered by multiple browsers.
- After registration, the user logs in by entering her email address into a login form comprising only an input box for the address and a submission button. The login form is displayed by all browsers on all devices, and the user can log in on any of those browsers. If that browser has a key pair credential, the user is immediately logged in. If not, the user is told that no credential has been found in the browser for that email address, and offered a one-click option to request a link that will create the credential and log the user in, when opened on that browser.
- The apps allow key pair credentials for multiple email address to be stored in the same browser. I believe this is a desirable feature, because members of a household may share a browser, or a user may want to register multiple email addresses with the same web app for multiple personas.
- The apps also allow a user to be simultaneously logged in on multiple browser, whether this is permitted could be a configurable policy in more elaborate implementations.
This user experience solves the loss-of-credential problem because there is no device enrolling, and recovering from the loss of a device that has been replaced, lost, or stolen is a simple matter of logging in on a browser running on a new device and opening a link on that browser.
How persistent is browser storage?
In March
2020, Apple
announced that, as part of its Intelligent Tracking Prevention
(ITP) policy, Safari was putting a 7-day cap on the persistence of
all script-writable storage, including localStorage
and IndexedDB. Storage would be deleted “after
seven days of Safari use without user interaction with the
site”. The policy was implemented by WebKit, and thus
affected not only Safari, but all browsers running on Apple devices,
which are required to use WebKit.
After developer complaints, however, Apple announced that it was going to exempt from ITP the domain of any web application that had been added to the home screen. Thus a web app that uses cryptographic authentication with a key pair stored in the browser can prevent deletion of the key pair by asking the user to add the app to the home screen of the device. This can be done without burdening the user by putting a link or button to do so on the registration page or on the page offering to send a credential-creation link to a new browser, upon detecting that the browser is running on an Apple device. If the user does not add the app to the home screen and the credential is deleted, the user will find out that this has happened when she tries logs in, and can easily recover and effect the login by requesting the credential-creation link and opening it in the browser as per the above user experience.
How secure is browser storage?
The FIDO Alliance presents the lack of adoption of FIDO authentication in the consumer space as the result of a trade-off between security and usability. The white paper goes over a history of online authentication, saying that “FIDO started from the top” by addressing high security use cases that required hardware-based authenticators, and proposing to “bring up the bottom” by using the less secure multi-device credentials that Apple, Google and Microsoft are devising to address consumer use cases.
There is an interesting three-way comparison to be made between the security provided by the single-device credentials that are now provided by platform authenticators, the multi-device credentials that are being proposed, and the single-browser credentials demonstrated in the two web apps. I will try to make that comparison in the next post.
The next post is now available.