Are Passkeys actually more secure or just convenient?

A few years ago, Passkeys became standardized and saw rapid adoption—even from websites and companies I would not have expected to so quickly adopt new technology, such as The Home Depot and Nintendo. The promise was that Passkeys were a highly secure and convenient (two characteristics that seem to be locked in a zero-sum game) replacement for all contemporary authentication methods: the death of the password, no more codes texted to your cellphone to be intercepted by hackers.

This viewpoint is compelling, but I’m generally skeptical. So, I needed to do more research for myself. I’ll attempt to assuage my curiosity (and yours) here.

Predecessors to Passkeys

Anyone who has used a computer has probably created a password. An ideal password is one only the owner of an account knows and which is not easily guessable by anyone else: human or computer. However, because human memory is finite and most non-advanced users don’t want to keep track of multiple passwords, it was common to reuse the same password across multiple accounts. Unfortunately, if that password was compromised by any means, it could be used to access multiple accounts: not just the one which had originally been compromised.

This led to the development of two-factor authentication, which required a second form of authentication, like a one-time code sent to a user’s phone, to log in. While more secure than a single password, two-factor authentication had downsides, like the potential interception of the one-time code, through various means including tricking cellphone providers into forwarding texts to the wrong phones.

To mitigate this telco danger, sophisticated users could use their own authenticator apps like Google Authenticator or Authy to generate codes securely on devices they had better control of. Unfortunately, the average computer user wouldn’t manage this or protect their token generator well. Even if a user uses an OTP generator on their own device, they could still be fooled or coerced into providing that code to an attacker in real-time.

Passkeys aim to solve these issues using public-key cryptography. They eliminate the need for a password or one-time code, providing a more secure and convenient login experience.

How Passkeys work and their security properties

Passkeys are based on public-key cryptography and designed to replace traditional passwords. Two underlying specifications enable the combined solution: W3C Web Authentication (WebAuthn) and Client to Authenticator Protocol (CTAP) (sometimes called FIDO2).

For developers implementing Passkey support in applications, WebAuthn is the most visible part of this stack.

The Client to Authenticator Protocol is lower level and describes the communication between the authenticator and client over different transports suitable for the client (e.g., Bluetooth or NFC if appropriate hardware is available).

The user experience and flow looks like this:

1. A User seeks to register a Passkey with a service (e.g. The Home Depot, Google).
2. A keypair is generated on the User’s device. The private key is stored locally and the public key is provided to the service.
3. Later, when signing in, the service sends a unique challenge string for each attempt to the User’s client.
4. The User’s client uses the private key (only it has) to cryptographically sign the challenge and return it to the service.
5. The Service can verify that the User’s client possesses the private key using the signed challenge and the known public key, ensuring it has authenticated with the Passkey owner.

This flow has several important qualities:

Every login attempt uses a unique challenge, making it impossible to reuse the same passkey between services: even if an attacker obtained a signed response, it wouldn’t be valid in future attempts.

It’s more resistant to server breaches, since only the public keys are stored on the server. If the service was compromised, the private keys forming the other half of those key pairs would remain out of reach of the attackers.

Comparing Passkeys to Password+OTP

Phishing resistance

Passkeys are more phishing-resistant because they’re tied to the DNS domain of the service, so they can’t be used on imposter sites. Browsers and operating systems often enforce this. In contrast, with passwords and OTPs, users can be tricked into entering their password and an OTP into a phishing website.

Replay attacks

With passkeys, the private key never leaves the user’s device, so it cannot be stolen in a server compromise. Even if a challenge response is intercepted, the private key cannot be derived from it.

In traditional password + OTP systems, both factors are vulnerable to theft. Passwords can be acquired through breaches or phishing, and OTPs can be intercepted in transmission (at the Internet level or telco provider) or through phishing.

With passkeys, there’s little risk of credential reuse or replay attacks because even if the exchange were intercepted, the server challenge would differ in subsequent logins and thus the signed response. Any captured signed response would only be useful if the server issued the same challenge again, which it shouldn’t: a situation I’ll discuss next.

Implementation risk

While passkeys are designed to be secure, recent vulnerabilities have shown that implementation flaws can introduce risks.

CVE-2024-9956 allowed attackers within Bluetooth range to phish passkey credentials via a flaw in mobile browser handling of authentication requests. This vulnerability was quickly patched, but it highlights that no system is immune to flaws in implementation.

So far, such vulnerabilities have been rare and quickly addressed, and the fundamental design of passkeys seems robust if implemented correctly.

Another example of an exploitable implementation flaw regarding the origin (domain) restriction on Passkeys came to mind:

The “Relying Party ID” verification of the WebAuthn spec details how browsers or authenticators should enforce not sending a passkey challenge response to a service that doesn’t match the Passkey’s original origin. For example, the browser should never send a signed challenge response from a homedepot.com Passkey to any external service not verifiably in control of that domain.

It is critical to implement this restriction in a browser or OS. Circumventing it would allow man-in-the-middle attacks where the attacker relays the service challenge and signed challenge responses.

Conclusion

Passkeys are a genuine security improvement even for users such as myself who have pretty strong security hygiene. They’re more convenient to use and I’ve enjoyed seeing pretty broad support and implementations of them in browsers and OSes. I keep mine stored in 1Password and appreciate how vendors like Chrome and Apple, with their own Passkey storage solutions, allow me to use those Passkeys quickly and easily without much judgment or upselling.

While no system is perfectly secure and flaws can occur, the overall security of passkeys is at least equivalent to, and generally better than, password + OTP—especially as the ecosystem matures.