Passkey misconceptions

[Dolda2000]

Being that so many people, including at LTT (judging by the TQ and latest WAN show) seem to fundamentally misunderstand Passkeys, as someone who has implemented them by myself on my website, I just really wanted to address some it, in a Q&A format. Thanks for coming to my soapbox!

 

1. What are passkeys?

Passkeys are not a particular implementation -- it's not the screenlock/biometrics on your phone, it's not the browser, it's not your password manager. Passkeys are primarily a more abstract concept that than; they're primarly a protocol, implemented by the server you're authenticating to, and an actual authenticator, and mediated by (going through) the browser. The authenticator can be your phone, it can be a Yubikey USB key (or any of the countless clones), a password manager, or some other component (including notably Windows Hello).

 

Importantly, and if there's only one thing you take with you from this post: the central problem solved by the passkey protocol is ensuring that only the same authenticator that created the passkey can be used later on to authenticate with the same passkey.

 

2. What's up with the biometrics thing? (aka. "I don't want tech companies knowing my fingerprint", or "you can change your passwords, not your fingerprint")

The server doesn't know your fingerprint and never will. Biometrics, while commonly touted as part of passkeys, is entirely circumstantial, and don't have anything with passkeys themselves to do. A passkey itself is just an asymmetric keypair -- the only thing the server will ever learn is the public key. Biometrics is just one way that can be used (and that some authenticators do use) to unlock the private key and allow for its use, but that is a completely local operation. If your authenticator is your phone, then the phone's software just uses your fingerprint/face-scan/whatever internally to authorize the use of the private key for the passkey in question. The server doesn't even know if your authenticator used biometrics or some completely different method to use the private key (except in cases of authenticator attestation, but that's a feature not normally used, at least outside corporate environments, and your browser will warn you if a site tries to use it).

 

In other words, your account isn't compromised by an attacker learning your fingerprint, other than if they also have your phone (or other authenticator that uses your fingerprint) and can specifically fool it into believing the fingerprint copy. The fingerprint can't even be used in any way separately from the authenticator that wants it. If your phone is compromised, all you have to do is replace the passkey on the account.

 

3. So what's the advantage over passwords?

The main advantage is that the protocol itself is so secure that the responsibility for security factors can be entirely delegated to the authenticator. Due to the asymmetric encryption, and the challenge-response-based protocol being used, it is pretty much entirely certain that any possible security issue is going to lie with the authenticator, and not with any other link in the chain; and as mentioned above, that's the central issue solved by the protocol: to ensure that only the authenticator that created a passkey can then be used authenticate with it. Passwords can be exfiltrated, leaked, sniffed, replayed, phished, and so on and so forth. With passkeys, the protocol itself protects against all of these problems, and the intention is therefore that the server doesn't really have to enforce particular security properties like MFA and whatnot. It can just completely trust that the authenticator does that part.

 

And that means that it can be up to the user to choose authenticators that fulfill their security requirements. If you're fine with an authenticator that just takes a password (like KeePassXC and many other password managers, or even non-biometric Windows Hello), that can be your choice. Even then, it's a lot more secure than a server-based password, because the password itself is again only used locally, on the client machine, to unlock the private key. It never leaves the client system, and therefore can't be intercepted/replayed/phished/&c (and again, even if it were, it would still be useless without the authenticator itself, which requires it). On the other hand, if you're more paranoid, you can use more secure authenticators, like USB keys, which brings us to...

 

4. So how does MFA work with passkeys?

The central insight here is the same as above -- the passkey protocol itself is so secure, that MFA policies can be left entirely to the authenticator. If the authenticator in MFA-capable (as, for example, a smartphone with biometrics, combining "something you own" and "something you are" in itself), then that in itself makes for the multiple factors. The protocol's security guarantees ensures that a particular passkey cannot be used without the full cooperation of the authenticator that created the passkey in question, so if that authenticator requires multiple factors to use the passkey, than it can't be used without those multiple factors. The key insight, again, is just that the responsibility for MFA enforcement is moved from the server to the authenticator. It is also worth noting that almost any passkey authenticator almost automatically is a MFA authenticator, because needing the private key means that you always need the authenticator itself, being the "something you own" factor. As long as the authenticator itself requires any authentication whatsoever to use it (biometrics, PIN code, password) and that authentication is another factor, then it's MFA. So even purely password-based authenticators like KeePassXC are effectively MFA authenticators.

 

5. How can passkeys guarantee security against phishing?

This depends a bit on the exact definition on passkeys, but as long as you're using them on a website, through your browser (therefore using the WebAuthn API), the browser itself ensures that the domain name (or more precisely, the origin) of the website the passkey was used on is included, unmodified, in the data that is signed by the private key. Since it is signed, it cannot be modified in transit by a malicious website, and therefore a server can detect if the passkey response was generated on a phishing site (which would have a different domain name/origin) and forwarded to the real site, unlike the case with passwords or OTPs. Strictly speaking, this depends on more than just the security of the authenticator itself by assuming that your browser hasn't been compromised/exploited, but if it has, you probably have bigger problems than phishing anyway.

 

6. If the security is delegated entirely to the client side, how can the server trust it?
Strictly speaking, it can't. The important realization is (again) that a particular passkey can only be used by the exact authenticator that created it (since creation also happens on the client side), so the user can know what factors the authenticator requires in order to use the same passkey later on for authentication. But the server strictly speaking doesn't know if the authenticator in question is a physically hardened USB key or a stupid software implementation that doesn't even ask for any other factors. Strictly speaking, servers can ask for authenticator attestation (briefly mentioned above) when the passkey is created, which will then include a manifest of the authenticators make, model and capabilities, signed by its manufacturer, essentially allowing a server to maintain lists of authenticators it allows or forbids the use of, but like I mentioned above, this is mostly intended for corporate environments or sites with much more extreme security requirements (like banks and such), and many authenticators (including, I believe, iOS devices) don't even support it. The central intention really is that the choice of authenticator can be left to the user.

 

That's it for now! Thanks for letting me get that off my chest.

[Dolda2000]

Perhaps also a note on terminology, since it tends to be a bit confused:
 

The term "passkey" itself isn't very strictly defined. Fundamentally, a passkey is a FIDO authenticator, where FIDO is the organization that formulated and standardized the protocol design, but FIDO authenticators can have various different properties (including or lacking support for such things as User Verification, Discoverable Credentials or Cloud Syncing/Backups), which affect how and where they can be used. Many people (myself included) use the term "passkey" for any FIDO authenticator, but there are notable exceptions, for example with Apple, which I think defines a "passkey" as an authenticator that supports all three of the previously mentioned features. I also believe many people in the WebAuthn working group believe a "passkey" is one that supports at least user verification and discoverable credentials, but not necessarily backups.

 

"WebAuthn", for that matter, is strictly speaking the JavaScript API that allows websites/services (referred to as "relying parties" in the standards) to request passkeys or passkey authentications. Since WebAuthn is such an important usecase for FIDO authenticators, it has also formed many aspects of the protocol, but it isn't the protocol itself, strictly speaking.

 

It is perhaps worth noting, also, that the term "PIN code", which most of us think of specifically as a short password of only numbers, is used very differently in these contexts, usually referring to any password, just so long as it is only used locally, for instance for unlocking a passkey, instead of being transferred to the target website/service to allow it to verify the password itself. That's why Windows Hello asks for a "PIN code" instead of a "password".

[20ReliableLights]

I didn't read all that but did it mention that their primary weakness is every site/app that I've used one with has a fallback in case you lose access to your phone (authenticator)? That fallback is usually your old school password, a one time code sent to your email, etc.

[Dolda2000]

Well, I mainly wanted to write about Passkeys themselves, not on extended account security, but there are probably a few things that can be said about authentication fallbacks.

 

For one thing, I don't think it's reasonable to not have fallbacks of one kind or another -- whether the main authentication method is passkey, password, OTPs or otherwise, because no matter what the authentication method is, there are absolutely going to be people losing it, and I don't necessarily think this even has to be a problem.

 

Especially when it comes to e-mail codes/links (which I too prefer as a primary fallback), there's no reason you shouldn't be able to secure your e-mail account just as well as the account that it's used as a fallback for, so that really shouldn't have to be a problem at all.

 

Also, you say it like it's a bad thing, but allowing a password as a fallback is exactly the way I implemented on my site, and quite intentionally so. To begin with, if you want to disable password as a login, really, just generate a 256-bit random password, set it, and don't save it. Now you've effectively disabled password logins on that account. (Well, I guess, except if the site in question saves passwords in plaintext or something, but if that's the level of security they're using, your account on that site probably never was secure to begin with anyway...)

 

Even if you don't do that, though, I think having the highly secure alternative of logging in with a passkey by default enables the practice of just using a much longer and more cumbersome password as a fallback, since you don't need to worry about the convenience of logging in "in the common case". Also, using passkeys in the common case and the password really just as a fallback minimizes the exposure the password sees, and just that is a good thing.

 

It should also be said that any site implementing passkeys in a reasonable way will allow you to register multiple passkeys, so that they can serve as fallback for each other (the only site I've seen to violate this principle is PayPal; shame on them).

 

Generally, I think it's great that sites allow users to choose the level of security that they themselves are comfortable with (analogously with how I mentioned that passkeys delegate the choice of authenticator security to the user), and this is a principle I've tried to apply to my own site as well. For instance, I hardly implement any minimum password requirements at all, but instead integrate zxcvbn to score users' passwords and kind of gamify it, encouraging them to choose good passwords rather than implementing arbitrary rules that they have to work around instead. Granted, account security is kind of hard, and delegating it entirely to the user may not always be the absolutely best choice, but it's at least something I myself appreciate as a user of services.

[SpaceGhostC2C]

6 hours ago, Dolda2000 said:

Especially when it comes to e-mail codes/links (which I too prefer as a primary fallback), there's no reason you shouldn't be able to secure your e-mail account just as well as the account that it's used as a fallback for, so that really shouldn't have to be a problem at all.

Secured how? With a passkey that also has password/recovery e-mail as a fallback? And how are the recovery methods for the e-mail secured, including a fallback?
Is it turtles all the way down?

 

6 hours ago, Dolda2000 said:

Even if you don't do that, though, I think having the highly secure alternative of logging in with a passkey by default enables the practice of just using a much longer and more cumbersome password as a fallback, since you don't need to worry about the convenience of logging in "in the common case". Also, using passkeys in the common case and the password really just as a fallback minimizes the exposure the password sees, and just that is a good thing

It also almost guarantees that the password will be forgotten, though, so it's like the fallback for passkey becomes whatever password recovery method you have.

 

Not that I have anything against passwords anyway, it's just that it doesn't matter what the shape of the whole overall chain is, only the strength of the weakest link (like Microsoft forcing you to use pre-defined recovery questions whose answers are completely obtainable by third parties - only way to secure it is to use false answers or just an alternative password you hope to remember as the answers...)

[Mihle]

On 4/28/2026 at 6:04 PM, 20ReliableLights said:

I didn't read all that but did it mention that their primary weakness is every site/app that I've used one with has a fallback in case you lose access to your phone (authenticator)? That fallback is usually your old school password, a one time code sent to your email, etc.

Some sites allow you to turn login with password off, for example I believe google do if I remember correctly. It does not happen automatically when adding passkeys.

 

More sites should allow it. For pages that do allow it, you as an user have to have backup in form of for example having two+ passkeys in a way you know you won't loose all of them.

[corrected]

The best implementation of passkeys I've seen is Microsoft account security options. All in one page, for login options, you can add/remove a password, many security keys, many devices. If a password is attached to the account, they support using the FIDO2 key as MFA (no pin required). But the page also encourages removing the password entirely.

On 4/29/2026 at 12:30 AM, SpaceGhostC2C said:

Not that I have anything against passwords anyway, it's just that it doesn't matter what the shape of the whole overall chain is, only the strength of the weakest link (like Microsoft forcing you to use pre-defined recovery questions whose answers are completely obtainable by third parties - only way to secure it is to use false answers or just an alternative password you hope to remember as the answers...)

Just for any new reader, this is out of date, Microsoft doesn't have an option for security questions now.

 

[LAwLz]

On 4/29/2026 at 9:30 AM, SpaceGhostC2C said:

Secured how? With a passkey that also has password/recovery e-mail as a fallback? And how are the recovery methods for the e-mail secured, including a fallback?
Is it turtles all the way down?

I think this is kind of treating recovery as if it is a passkey-specific problem though. It isn't.

The same thing applies to passwords. If you forget your password, there is usually a reset flow. If you lose access to your TOTP app, there are backup codes or some other recovery method. If you use a hardware security key, you had better have another one somewhere, because otherwise losing it can lock you out.

You're right that recovery has to end somewhere. That is true for every login method. I don't think that says much against passkeys specifically.

 

 

 

 

On 4/29/2026 at 9:30 AM, SpaceGhostC2C said:

It also almost guarantees that the password will be forgotten, though, so it's like the fallback for passkey becomes whatever password recovery method you have.

Maybe, but only if the password is something you're trying to keep in your head.

 

If I use a passkey for normal login and keep a long random password in a password manager as fallback, I don't really care whether I remember it. In fact, part of the point is that the password no longer needs to be convenient. It can be ugly, long, and basically never typed.

 

And even if a password fallback still exists, I don't think that makes the passkey meaningless. A password that you almost never type is exposed much less often. It is less likely to be entered into a fake login page, less likely to be reused somewhere, less likely to be captured by some dodgy device or browser extension, and less likely to matter in day-to-day attacks.

 

It's like saying there is no point putting a lock on your front door because there is also a spare key somewhere. Sure, if the spare key is under the doormat, that is bad. But the conclusion from that should not be "locks are pointless". The answer is "don't keep the spare key somewhere stupid". A good lock still makes the normal way into the house much harder.

 

 

 

On 4/29/2026 at 9:30 AM, SpaceGhostC2C said:

it doesn't matter what the shape of the whole overall chain is, only the strength of the weakest link

If someone can recover your account by answering "what was your first pet's name", then yes, that is a terrible weak point. No argument there.

 

But most attacks are not some perfect movie-hacker thing where the attacker calmly maps out every possible route into one account and then picks the weakest theoretical path. A lot of real attacks are phishing, credential stuffing, reused passwords, leaked databases, fake login pages, and other boring stuff that works because passwords are easy to steal and replay.

 

Passkeys help a lot with that. They don't fix every possible recovery problem, but they do remove a bunch of common attacks from the normal login flow.

If you want another analogy then think of passkeys as seatbelts. A seatbelt does not make the car indestructible. It does not fix bad tyres, drunk drivers, icy roads, or the fact that someone can still crash into you. But that would be a weird reason to say the seatbelt does not matter. It reduces a big category of risk in the common case, which is still valuable.

 

So I agree that bad recovery can undermine a good login method. But I don't agree that this makes the good login method irrelevant.

 

You are thinking of this in too black-and-white terms.

[SpaceGhostC2C]

On 5/2/2026 at 2:53 AM, corrected said:

 

Just for any new reader, this is out of date, Microsoft doesn't have an option for security questions now.

 

Have they removed it very recently?
To be clear, I was referring to the requirement in Windows during installation (in W10 and W11 when creating an offline account, in W7 it asked for a "hint" to your password instead), not Microsoft cloud accounts.

[SpaceGhostC2C]

On 5/2/2026 at 6:11 PM, LAwLz said:

I think this is kind of treating recovery as if it is a passkey-specific problem though. It isn't.

No it's not, it is universally valid.

On 5/2/2026 at 6:11 PM, LAwLz said:

The same thing applies to passwords. If you forget your password, there is usually a reset flow.

Yes, that is exactly the point. I don't think it's getting across.

My only point is: you may face a trade-off of convenience and security and you have to make a choice. If some very secure method happens to have an "inconvenience" (by some perspective), then so be it, but it's not "fixed" by having a less secure but more convenient fallback. If you set up the most robust door in history at the front of your house, you'll be very secure, but no locksmith will get you in if you ever lose your key. You may also have a door you can kick in any time you like, lost keys or not. You may prefer either. AFAIK, crypto wallets would be examples of choosing security against all convenience. Other use cases end up in "admin - admin" passwords because only convenience matters to them. But if someone asks about the inconvenience of the first choice, the answer cannot be "don't worry, I also have a backdoor that's always open for that scenario" and still think you have a secured door.

 

If you use any method, like passwords all the way down, then you are secure and convenient as passwords are. Same with any other method. The moment you mix and match, though, you are as secure and as convenient as the least secure and most convenient method in the chain. In the context of the advantages of one method over another, the question by @20ReliableLights was pertinent. If the answer is a password-protected method, then passkeys aren't better than passwords after all. Instead, if the fallback is another passkey then we are back in the first case and effectively the answer to

On 4/29/2026 at 3:30 AM, SpaceGhostC2C said:

Is it turtles all the way down?

is: yes. So, it's not that a collection of passkeys as authentication and fallbacks isn't valid. 

 

[LAwLz]

3 hours ago, SpaceGhostC2C said:

If some very secure method happens to have an "inconvenience" (by some perspective), then so be it, but it's not "fixed" by having a less secure but more convenient fallback.

But I don't think that has to be the case. A fallback can be less convenient than normal login. Backup codes stored somewhere safe, a second hardware key, a long random password in a password manager, recovery from an already trusted device, delays, notifications, support review, and so on.

That is not the same as an always-open backdoor.

 

 

3 hours ago, SpaceGhostC2C said:

The moment you mix and match, though, you are as secure and as convenient as the least secure and most convenient method in the chain.

This is where I disagree with you, and I feel like you are having a bit of tunnel-vision.

 

Sure, if one weak recovery path can take over the account, then that weak path matters. No disagreement there.

But a password typed into websites every day is not exposed in the same way as a long random password that sits in a password manager and is almost never used. The second one may still be a fallback, but it is much less exposed to phishing, reuse, credential stuffing, fake login pages, and leaked password databases.

 

So even with a password fallback, passkeys can still improve the normal login flow by providing protection against the most common types of attacks.

Keyloggers is one of the most common types of attacks that exist, and passkeys provide protection against that every time you use it. Keyloggers do not work if you don't type in your password. The potential for someone to obtain your password and then using that to login still exists, but the use of passkeys removes a lot of the opportunitets for that to happen.

[corrected]

On 5/3/2026 at 8:45 PM, SpaceGhostC2C said:

Have they removed it very recently?
To be clear, I was referring to the requirement in Windows during installation (in W10 and W11 when creating an offline account, in W7 it asked for a "hint" to your password instead), not Microsoft cloud accounts.

Ah, I interpreted that as Microsoft cloud account. I personally don't see the purpose in increased security for windows login. I don't even use a screen lock for my phone. Simply don't let others use your device.

 

On 5/3/2026 at 9:16 PM, SpaceGhostC2C said:

The moment you mix and match, though, you are as secure and as convenient as the least secure and most convenient method in the chain

Just don't do this? All implementations I've seen support using only backup codes which are another "something you have".

 

I use passkeys to remove any "something you know" forms of authentication, aside from being faster - I just type the pin and touch the thing, and some websites don't even need a username. If the "something you have" is always on me physically, then I can be sure that my account is safe unless someone has broken into my home and taken it from me, then in that case I have other things to be worried about.

[20ReliableLights]

On 5/4/2026 at 11:16 PM, corrected said:

I don't even use a screen lock for my phone. Simply don't let others use your device.

And don't ever lose it or have it stolen from you. Kind of scary to not use a screen lock with the amount of private information we keep on our phones but to each their own.

[Mark Kaine]

I mean a lot of services don't require a password at all anymore, they just ask "do you want to be a passkey bro?"

I think that's at least some progress? It's probably a lot harder to reverse/social engineer that ("nobody will guess that my pw is password123 anyway!")