User Experience

Using a browser as a credential wallet

From the very beginning of the web, browsers have been used as credential wallets to store and present cryptographic credentials, which makes sense since the browser is the user’s agent on the web. But only TLS certificates have so far been supported, and proof of possession is inconveniently provided, during the TLS handshake, to transport-layer rather than application-layer code of the network stack of the relying party.

In Chapter 12, Section 12.4, of the book on Foundations of Cryptographic Authentication that I’m writing with Sukhi Chuhan and Veronica Wojnas, we show how a browser can be used as a credential wallet using standard application-layer web technology, for any kind of cryptographic credential, including full disclosure and selective disclosure public key certificates and anonymous credentials. Sections 12.4.2.1-3 have graphical descriptions of protocols for credential issuance and same-device as well as cross-device credential presentation. There is also a description of a protocol for presentation to an unattended IoT device, that can be used for providing authenticated physical access to a facility.

A Demonstration of Two-Factor Cryptographic Authentication with a Familiar User Experience

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.

FIDO2 and WebAuthn have momentum but won’t help if they are not used

March 18, 2023: The preprint referenced below has been updated to add a patent disclosure.

FIDO2 and WebAuthn have momentum. They are supported on all browsers. Apple, Google and Microsoft are busy developing or releasing initial versions of passkey syncing. NIST now requires resistance to phishing attacks at Authentication Assurance Level 3 of the Initial Public Draft of Revision 4 of the Digital Identity Guidelines. CISA has endorsed FIDO as the gold standard. And all the tech blogs are announcing the demise of passwords that FIDO will bring.

But a year ago the FIDO Alliance announced in a white paper that FIDO authentication “has not attained large-scale adoption in the consumer space.” Has that changed? Is it changing? Is it ever going to change?

The FIDO Alliance white paper coupled the announcement of the lack-of-adoption problem with a diagnosis of the problem and the announcement of an upcoming solution. The problem was due to the 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”. Apple, Google and Microsoft were going to provide the solution by syncing credentials across devices. The term “passkeys” was coined to refer to synced credentials.

Apple, Google and Microsoft are keeping their promise and diligently working on the solution. Kudos to them. But FIDO authentication has daunting problems that are not addressed by passkeys.

One of them is the reliance on the device unlocking mechanism, e.g. Windows Hello in the case of a Windows laptop, to provide a second authentication factor supplementing the proof of possession of the private key. A user who does not set up device unlocking cannot use FIDO. How many users set it up? I couldn’t find any statistics about this, but I thought of people who would know. Geek Squad Agents work full time helping people set up and repair their devices, so they intimately know how consumers use laptops and smart phones. I interviewed one of them: “How many Windows users set up Windows Hello?” He said: “30%; just a guess.”. I thought he had misunderstood the question, so I asked again: “You mean as many as 30% do NOT set it up?” He replied: “No, MOST do not set it up. I’d guess about 30% set it up.”.

Another big problem for FIDO is its positioning as passwordless authentication. There are three kinds of authentication factors: knowledge, possession, and inherence. Advertising an authentication technology as being passwordless is advertising it as lacking one kind of factor. That’s a bad thing, not a good thing. I guess the slogan originated when people started using many web sites, and were told not to reuse passwords, and were having trouble remembering many different passwords. But that’s a problem that disappeared more than ten years ago when, first password managers, and then browsers, started keeping track of passwords.

Today users love passwords, and they resist having to use anything else. A password is the only authenticator factor that the user has full control over. It is the quintessential self-sovereign authentication factor.

I’ve just put online a preprint of a paper entitled “Overcoming the UX Challenges Faced by FIDO Credentials in the Consumer Space.” The previous post was an extended abstract of the paper. The full paper gives the details, with figures, of two authentication protocols. The first one uses existing FIDO credentials and provides an incremental improvement on the FIDO user experience. The second protocol removes the major obstacles to the adoption of FIDO2 and WebAuthn, using enhanced credentials and an extension of WebAuthn. It does not require a Windows user to set up Windows Hello, and uses as a second factor a full fledged password, not a PIN or a biometric, cryptographically protected against reuse, data breaches, and phishing attacks by being combined with the cryptographic factor into a joint authentication procedure.

Overcoming the UX Challenges Faced by FIDO Credentials in the Consumer Space

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.

A User Experience for Strong Authentication in the Consumer Space

This is the last post of a four-part series on cryptographic authentication. Links to earlier posts can be found at the end of this post.

A few months ago I was talking with a business woman about technology topics. As I was trying to explain the concept of cryptographic authentication with a key pair, she asked: what if the attacker steals the computer?

She then told me that a boyfriend had once stolen her computer and used it to launch a devastating attack against her life, which it took her months to recover from, by impersonating her on the internet. We did not discuss the details of the attack, but it is easy to imagine how it may have been carried out. He may have screen-unlocked her computer using her PIN, which she may have given to him before they became estranged, or he may have obtained the PIN through shoulder surfing. Her browser may have saved all her passwords and supplied them as he logged in to her financial and social media accounts with the stolen computer. He may also have been able to extract the passwords from the browser and transfer them to his own computer, using the same PIN to authenticate to the browser.

As I remembered this story I realized that I had missed this attack as I listed attacks relevant to the consumer space in part 2 of the series. I did list theft of the computer by a determined attacker who plans ahead and mounts a prior attack to get the PIN. But this attack is different because the attacker has to make little or no effort to get the PIN if he lives in the same house or apartment as the victim or visits often. It is also a different kind of attack, because the the goal of the attacker is to inflict pain rather than to obtain information or material gain. Together with cyberstalking and other forms of digital abuse against women, the attack belongs in a category that deserves special efforts to protect against. Yet FIDO2 and WebAuthn provide no defense against it, since no password is used, and only a PIN is required to unlock a credential.

A password-centric user experience

Remembering the story also made me rethink the user experience that I was going the propose in this blog post for the strong authentication method that I specified in the previous post (part 3).

Passwordless Authentication for the Consumer Space

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.