Will passkeys ever replace passwords? Can they?

Systems Approach I have been playing around with passkeys, or as they are formally known, discoverable credentials.

Think of passkeys as a replacement of passwords. They are defined in the Web Authentication (WebAuthn) specification of the W3C (World Wide Web Consortium). This work evolved from several prior efforts including those of the FIDO alliance (FIDO = Fast Identity Online).

My quick take on passkeys is that they are a good idea, and if we could convince the world to use them instead of passwords, we would all be much better off. Phishing in particular should take a big hit if they are widely adopted. But I fear that this isn’t likely to happen, for reasons that I will explain in a moment.

In the perennial quest to create more secure systems that are also user friendly, some significant implementation issues are apparent. My experience reinforces my belief that a systems view of security is necessary and user interactions with the system must be carefully thought through.

The basic idea behind passkeys is straightforward enough: A user (or more likely, a device owned by the user) creates a private/public key pair specifically for a single website and provides the public key to the site. The user proves their identity to the website using some other method such as a previously established user name and password, maybe some other factors as well. The website stores the public key for subsequent use. The next time the user wants to authenticate to the website, the site issues a challenge to the user, who uses the locally stored private key to sign their response to the challenge. The website uses the stored public key to authenticate the user.

Key points

This is why we say passkeys replace passwords, specifically with public key cryptography. Because the user’s private key never leaves their device it should be much harder for a phishing attack to succeed. Phishing normally relies on getting a user to divulge their password by entering it into a bogus site. (Sophisticated attacks sometimes get users to divulge their second factor, such as a one-time code from their phone, as well.)

Passkeys, as well as remaining local to the user’s device, are unique to a particular site – implementations verify a certificate from the designated site before the relevant private key is used to respond to a challenge. So you can’t accidentally use a passkey on a bogus site. Similarly, the problems of password reuse across sites are avoided. Password reuse often means that a security breach on one site can be used to gain access on others. None of that happens with passkeys.

A systems approach to security should include viewing the user as part of the system

There remain a few weaknesses. The process is bootstrapped by getting the user to authenticate using a traditional approach (such as username and password) which remains open to traditional attacks. One way to mitigate this is to require multi-factor authentication (MFA) – and there are better options than one-time codes sent over SMS, which I will get to. There is no getting away from the fact that public keys always need some sort of bootstrap process. (Remember PGP key-signing parties?)

But if a website adopts passkeys without disallowing subsequent login attempts by password, then the system remains roughly as vulnerable to phishing attacks as it was before. A savvy user might detect that they are being phished if they are suddenly being asked for passwords after using passkeys for a long time, but any time we rely on the judgment of users to detect security attacks we are bound for disappointment. It bothers me to read blog posts from seemingly credible sources that don’t address the fact that passkeys are being added in addition to passwords but not (yet) replacing them. Maybe the time will come when passwords are the exception, but I see no way to get there on the current trajectory.

In practice

There are two broad categories of passkey implementation. One approach binds the key to a specific piece of hardware, such as a USB key (eg, Yubikey). Or a passkey might be stored on a mobile phone and require biometric authentication (eg, facial recognition) before the passkey can be accessed.

The second class of passkey implementation allows the credentials to be copied among multiple devices, typically using some sort of password manager to keep the credentials secure and synchronized across devices. In this case, the private-public key pair is stored in the password manager and then is made available to the user across different devices (laptops, mobile phones, etc.) when they need the passkey.

Hardware tokens make phishing attacks almost impossible (if they replace passwords, see above), since the only way to get access to the user’s credential is to have physical access to the key. A password manager, on the other hand, is a piece of software that normally has some cloud service behind it to handle synchronization across devices. If an attacker manages to get access to the credentials necessary to log in to the cloud service, then they have access to the passkeys stored within it. For this reason (among others) password managers are generally secured with some sort of multi-factor authentication. One of those factors might be biometric, or even a hardware token.

As an aside, I would note that there is considerable variation in the security of different password manager implementations. Lastpass, for example, apparently made some poor design decisions that meant a breach was much more serious than it needed to be. By contrast, 1password’s description of system security suggests that the only way the passwords (or passkeys) in their password manager can be accessed by anyone is if they have access to all your authentication factors (which in my case includes a hardware token.)

My last concern about passkeys is that the implementation seems to have failed the “make it easy for users” test, which in my view is the whole point of passkeys. I have been using public key cryptography for 30-plus years. (My first boss insisted his managers use PGP to encrypt emails containing sensitive information about employees – ah, those were the days.) Surely the reason for yet another technology based on public key cryptography is to simplify its use. If I find passkeys confusing to use, it doesn’t bode well for more typical users. Let me walk through an example.

User interfarce

I decided to try to add a passkey to my WordPress.com account on my Apple Mac. So I log in using my existing password and second factor (a hardware token). I navigate to the security page; there is no mention of passkeys, so I click “2-factor authentication” then “add a security key.”

OK, I’m not going to replace a password with a passkey here; instead I am going to add a security key as a second factor. And for the sake of this example, let’s say I want to store it on my Yubikey. When I click “add key,” three different bits of software compete for my attention.

First up is the password manager, offering to store a passkey. (This is the first time passkeys have shown up in this process – you can begin to see how a casual user might be getting confused.) I don’t want the password manager to be involved in this case, so I dismiss the window.

Next up, a window appears from macOS asking me if I would like to use TouchID to “sign in” (to what? – I am already signed in to the website) and to save a passkey. Again, note the different terminology. When I dismiss that window, it is time for the browser to have a go, offering me four ways to save a passkey, including finally the option to store it on the hardware token. I insert the USB key and proceed.

I think we can all agree that this is a confusing experience, with three different systems fighting to be the One True Place To Store Passkeys, along with the inconsistency of terminology (passkeys or security keys) and use cases (password replacement or strong second factor?)

It’s like every piece of software wants to “help” but there is noone looking at the system-level behavior where these different bits of software interact with each other and the end user. I’ve encouraged my wife (a social scientist not a computer scientist) to adopt a password manager and 2FA, and she’s very willing to follow my lead, but the confusion of terminology and bewildering arrays of options frequently (and understandably) leads to complete frustration on her part.

There is a longstanding trade-off between security and usability. It’s important to take a systems approach to security and that should, I believe, include viewing the user as part of the system. If you can’t make a security technology sufficiently easy for users, then it’s unlikely to provide good security.

Passkeys and the WebAuthn specification were intended to make public key cryptography accessible to average users, rather than just the domain of the tech-savvy. If done right, they could seriously improve security on the Web.

There is a well-defined API to allow a broad choice of authentication devices (such as FIDO keys or password managers) to manage the creation and use of private/public key pairs. But unless things get a lot more consistent and smooth for the end user, I fear this will end up just like PGP or client certificates in TLS: A technically valid solution that has minimal impact on the majority of users. ®