Yep, Passkeys Still Have Problems
100 points by adamcstephens
100 points by adamcstephens
Probably a dumb post, but: As someone who religiously uses 1Password and a unique very hard password for every site and 2FA when possible. Is there anything in passkeys for me?
I mostly hate that most sites have made it take LONGER than before to log in with “use a passkey” pop ups. Which makes me not try them on principle. When 1Password used to be a 2-3 click process. Now it’s a 3-4 click process on those sites.
It’s also annoying when they don’t have proper 2FA but instead let you log in with password then hit you with a “check your email and copy the code to log in."
Passkeys never get transmitted to anyone, which means that a buggy server, mitm, etc, doesn't get anything that can be used to compromise your credentials permanently.
Passkeys are problematic for other reasons, and I avoid them as a result, but wanting to replace passwords with pubkeys is very sound.
What are some of the problematic reasons that make you not use it?
Attestation, and the general fight the implementers have against the being fully in control of how I manage my keys.
There's a also stubborn refusal to realize that if a user loses one password, they can use email or similar to reset it, but if they lose a passkey device, they've lost all of their credentials at once, including the ones they could use to reset their credentials.
There's a also stubborn refusal to realize that if a user loses one password, they can use email or similar to reset it, but if they lose a passkey device, they've lost all of their credentials at once, including the ones they could use to reset their credentials.
Last I checked, the current approach to handling this is "buy another passkey." I'm not interested. I understand the appeal of having keys generated on the device and never leaving them. But I'm going to outlive those devices. And as such, my identity needs to outlive those devices too.
I've never seen a "buy a passkey" option. I'm not sure you're talking about the same thing as what the article is talking about. Maybe you mean YubiKey or something like that?
When you are in an environment that requires attestation you need to buy a key. Example: the cheapest key for the Austrian government ID is around 70 Euro last time I checked.
I'm going to take a different tack here: I don't think passkeys are "problematic", and I think most of the claims advanced to try to show they are... are problematic in themselves.
So, first let's be clear what "passkeys" mean: in traditional password auth, you select a password, the site stores it (ideally, some non-reversible value derived from it), and to authenticate you supply the password and the site compares against the value it stored. Passkeys are basically nicer branding for something called WebAuthn, which replaces this flow with one where you generate a public/private cryptographic keypair, and the site stores the public key while you store the private key. To authenticate, you prove possession of the private key by signing something with it, and the site uses the public key to verify the signature.
That's the core idea of "passkeys".
A lot of these discussions devolve into fearmongering about "attestation". "Attestation" is simply the use of cryptography to make an assertion that a third party can verify. Every PGP-signed email is an "attestation". Every time you access a web site over HTTPS, there's "attestation" in verifying that the site presents a certificate signed by an authority your device/browser trusts. "Attestation" is a neutral concept which gets hijacked and loaded up with emotional baggage and connotations to try to make it sound evil, usually by trying to tie it to an idea that third parties will take control of your devices and prevent you from fully "owning" something.
Usually with passkeys, this refers to a proposed feature that would have let corporate deployments choose a specific vendor's passkey client implementation and enforce use of it by employees, and which would have used cryptographic assertions to verify that. As far as I'm aware, the entire idea was actually scrapped and nobody ever implemented it. But it is still brought up over and over as if it's an inherent part of passkeys and as if it will be forced onto all users everywhere, rather than as just a bog-standard corporate-compliance thing, the same as the MDM features which let a company control a company-owned laptop or phone they issue to an employee.
Another usual bogeyman is concerns about not being able to export/transfer passkeys between client-side implementations (say, between the operating system's built-in passkey store, and a password manager application). This mostly goes back to a GitHub thread where an open-source password manager was asked to please not export private keys in plaintext; that's actually a reasonable ask, but has been portrayed as instead demanding that export and interoperability be banned. At any rate, export and interoperability for passkeys exist, today, right now, and you can use them. The flows had to be carefully thought about and designed because, again, they're dealing with cryptographic private keys which are inherently sensitive material, but the functionality is there and available to you if you want it.
The rest of the complaints tend to be a hodegpodge of things that aren't actually unique to passkeys. For example, it's possible a site using password authentication could refuse to implement an account-recovery mechanism if you forget or lose your password. Nobody uses that as an argument against passwords, but every time passkeys are discussed you'll see someone arguing that they're bad because hypothetically a site might not let you recover from losing access to your passkeys store. Same for "vendor lock-in". The person cited in the linked article, who got locked out of an Apple account, would be locked out regardless of the auth mechanism. If they insisted on only using password auth, but also on only using Apple's own password manager, well, having their Apple account locked would lock them out of those passwords. But nobody seriously considers this to be an argument against using passwords; many people do try to present it as an argument against using passkeys.
Attestation is not a hypothetical or scrapped idea. It is used today in at least one country (Austria) for government-issued digital IDs, specifically to require citizens to use government-approved passkey implementations. They have also revoked previous generation Yubikeys. In other words, attestation is actively being used to force the use of specific authenticators in real-world deployments, not just corporate IT scenarios.
Separately, while Apple does not rely on attestation for Apple ID passkeys, they have nevertheless implemented UX-level restrictions that effectively discourage or block enrollment of non-Apple passkeys. If there is a way to enroll a Yubikey for an apple account, please tell me how.
Neither of these points make passkeys "bad", but they do undermine the claim that concerns about control, lock-in, or enforced implementations are purely theoretical or fearmongering.
For example, it's possible a site using password authentication could refuse to implement an account-recovery mechanism if you forget or lose your password. Nobody uses that as an argument against passwords, but every time passkeys are discussed you'll see someone arguing that they're bad because hypothetically a site might not let you recover from losing access to your passkeys store.
I think one reason you end up with that argument is that the baseline is passwords, and the password reset flow is a known security issue which passkeys do not solve. But if you were to want to solve this, you would make passkeys mandatory and delegate the UX experience about passkeys to a third party so that you can never "lose them". Which paired with the rest of the issues of it, puts a lot of power into third parties.
An added problem is the amount of additional (at the moment still fairly esoteric) concepts that you have to deal with both as a naive and a conscious user of this technology is a huge creep in cognitive load. I feel it is both unjustified and not conscionable.
Agreed. And I have been in this situation with my mother who auto enrolled in a passkey on her Windows computer on a service (which we only learned later), not knowing it, being locked out from her iphone and we had to reset the account with customer support and by mailing in a government ID. You can trivially end up in a situation of pure user frustration if the website makes a handful too many assumptions about how good people are with retaining their passkeys.
Every PGP-signed email is an "attestation"
Really? How can I use PGP signatures to ensure that you only sent emails from a properly secured device?
Every definition of remote attestation relevant to the discussion includes one side proving to the other that the software involved has a known chain of custody. This chain of custody verification generally does not allow the user to customize, replace, or improve the system they use. Either you already knew this and are trying to muddy the waters, or you're not paying attention to the discussions.
Also, note: Strangely, almost nobody seems particularly concerned about proposing protocols that let the user verify that the software running on the server is exactly the software the user thinks they're connecting to.
The rest of your post also seem to be similarly full of straw men.
Edit -- Also:
but has been portrayed as instead demanding that export and interoperability be banned.
Perhaps because in that thread, they directly said that export should be banned, suggested using remote attestation to block interoperability with that client, effectively banning them. I encourage people to read the thread for themselves and come to their own conclusions on whether the portrayal is accurate: https://github.com/keepassxreboot/keepassxc/issues/10407 .
As far as I'm aware, the entire idea was actually scrapped and nobody ever implemented it.
Cool, maybe it can be dropped from the protocol specification, then? Everyone wins -- the protocol gets simpler, attestation becomes clearly unsupported, and adoption becomes easier because there's one less reason to object. It's a no-brainer.
Every definition of remote attestation relevant to the discussion includes one side proving to the other that the software involved has a known chain of custody.
You said "attestation", and expected it to be interpreted as "remote attestation", and expected that to be interpreted as a specific user-hostile application of remote attestation.
"Attestation" in the context of passkeys literally just meant letting client software to produce and send information identifying the client so that companies which want to enforce a standard vendor for their employee auth could do so. And that is dead in the water because major vendors don't implement it. Which I know for a fact you personally have been told in previous iterations of this discussion.
Your gotcha of "why don't they remove it from the spec" is basically asking that a W3C Recommendation be retroactively edited to remove a thing that ended up being unused. The W3C is not generally in the habit of doing that, so you'll have to wait for a new iteration of the spec and lobby for any related language to be dropped there.
Perhaps because in that thread, they directly said that export should be banned
Well, if we go read how the thread started, the person who opened the issue said (emphasis added by me):
Passkeys should never be allowed to be exported in clear text.
Which is the correct stance. They're private keys. They should be protected during transit.
The other usual thing people point to is this comment, in which the person being accused of evil intentions is again saying -- and again is correct! -- that copying and pasting plaintext private keys is not a thing that should happen. The whole thread is that person asking for some type of safer, non-plain-text format, which is not at all the same as "export should be banned".
You said "attestation", and expected it to be interpreted as "remote attestation", and expected that to be interpreted as a specific user-hostile application of remote attestation.
Are you unaware of the context that the term is being used in, or were you just not paying attention?
As for the rest of the message -- I strongly encourage people to pay attention to what was left out of the response.
I strongly encourage people to pay attention to what was left out of the response.
If you want to really encourage people to look at what's been "left out" of discussions...
You said the linked GitHub thread involved an assertion that "export should be banned". I provided full quotes and references from the thread showing that the person in question was asking for plain-text export of private keys to not be allowed, and was insisting that any export mechanism would need to protect the keys.
Yes, and I posted a link to the whole thread. I encourage people to read it, rather than looking at selected quotes.
Your gotcha of "why don't they remove it from the spec" is basically asking that a W3C Recommendation be retroactively edited to remove a thing that ended up being unused. The W3C is not generally in the habit of doing that, so you'll have to wait for a new iteration of the spec and lobby for any related language to be dropped there.
When that new iteration comes out without the ability to control what is running on the endpoints, and without the ability to enforce how I manage my own keys, I'll be happy to support it. Until then, I'll continue to recommend people stay away.
It's still annoying to see people refuse to acknowledge that key resets by email or other similar methods requires you to be able to access your email after you lose the device holding your passkeys, but when your less tech-savvy relative drops their phone in the lake, that's not my problem.
It's still annoying to see people refuse to acknowledge that key resets by email or other similar methods requires you to be able to access your email after you lose the device holding your passkeys, but when your less tech-savvy relative drops their phone in the lake, that's not my problem.
It’s annoying to see this repeatedly asserted as something unique to passkeys. If I store all my passwords in a password manager on a single device, and lose that device, I have the same problem.
The majority of non-technical people use their head as that single device, in spite of your dislike for that solution. When they fully lose access to that password storage device, they're rarely concerned about recovering passwords.
And if they forget their passwords? What then?
What if they forget their email password and lose their only device that's logged in to that email account?
It's always possible, with any auth mechanism, to come up with a hypothetical where the user loses access to all possible account-recovery methods. Why is it only blamed on the auth mechanism in the case of passkeys? Passwords are exactly as susceptible.
Passwords can be written down at least. Or have backups made of them, or whatever else I want to do with it.
Passkeys have the problem and benefit of being impossible for the user to see, so I think it’s fair to worry that something might happen to them without you being able to do anything about it.
The thread that's usually linked to claim that passkeys are not allowed to be exported out of the client software is actually a thread about forbidding plain-text export. Which, given that these are cryptographic private keys, is an entirely reasonable stance.
But even if we grant that somehow someone decides it should be somehow forbidden to have backups of passkeys, the fact remains that the same account-recovery flow that would be useful for a lost/forgotten password would also be useful for a lost passkey. It's only in the case of passkeys that people try to invent complex hypotheticals where someone loses their only device, forgets or loses all information they could use to verify identity through other means, etc. etc. and then blame that on passkeys.
The rest of the thread was threats of forbidding anything but on-TPM corporate owned storage. This is already explicitly allowed in the spec and used by Paypal iirc. And re: export I think extremely recently Apple has finally deigned to allow manual exports to a small subset of participating password managers so long as they keep Apple's blessing and before that they were impossible to move.
I can keep my email password & password manager password in my head, make a backup every so often, switch managers whenever I like, and be very confident I'm never going to lose anything. Using passkeys, I cannot say that. The keys aren't owned by me, they're owned by Googe/Apple/Microsoft and I have to have faith that they will keep allowing me to use them.
It's reasonable to not use passkeys if you don't like using them.
Just don't use them when you have the option to use them.
And if a company requires them, then don't use that company.
It seems like you would be well served by this option.
A lot of these discussions devolve into fearmongering about "attestation". "Attestation" is simply the use of cryptography to make an assertion that a third party can verify. Every PGP-signed email is an "attestation". Every time you access a web site over HTTPS, there's "attestation" in verifying that the site presents a certificate signed by an authority your device/browser trusts. "Attestation" is a neutral concept which gets hijacked and loaded up with emotional baggage and connotations to try to make it sound evil, usually by trying to tie it to an idea that third parties will take control of your devices and prevent you from fully "owning" something.
This has been a very frustrating commonplace of these conversations, so thank you for voicing this.
A reminder to everyone that a credential is not yours, it is a contract between yourself and a second party to establish identity. Enforcing terms of this contract has been an absolutely normal thing ever since password length requirements.
Judicial scrutiny of cartel exclusivity contract terms has also been normal things longer than computers exist.
cartel exclusivity contract terms
Perfect example of the absolutely ludicrous non-sequiturs the GP was talking about
Sure, but I’m free to use other options they provide (password/totp) if I think their contract is hostile to me.
Everything you say is 100% true, if we trust that Google, Apple, Microsoft, and their representatives at the FIDO Alliance are speaking and acting in good faith in all of these discussions. The problem is, I think, that we are having this discussion in 2025, where very few people are willing to place that trust in those institutions.
Implementation has been my main bugaboo. Simply put, if it doesn't support bitwarden, I am not interested. Last time I tried them they didn't support bitwarden. The alternative is painful and annoying complex key transfers between all of my devices, which is a big no thanks for me. Back when I was first trying them, there was no private key export mechanism.
I've been using passkeys with Bitwarden for some 2 or 3 years now and it works great. There were some issues on Android a year ago, because I think it couldn't be set as the default on Chrome? Maybe that's changed now. Either way, I'm on iOS now, and it's like the default password manager isn't even there. Everything just goes straight to Bitwarden. On macOS haven't tried it outside of Chrome, but there it works just fine too.
To be fair, I never tried key export. I self-host Vaultwarden and I back that up, and just have Bitwarden set up on all my devices.
I use passkeys with bitwarden no problem
There was some problems with older android OS that slowed me down a bit, but on newer Android/Win/MacOS/iOS I have no issues
Passkeys never get transmitted to anyone
How does this part work? I assumed you send your key to the server and it checks if matches the other part of the pair.
Nope, you use your private key to sign some data the server sends you. You then send it back and the server uses your public key to verify the signature.
You send the public part of the key (you might consider it a fingerprint of the key), but the private part is used to basically public-key-sign a sign-in request message.
There were some systems that took passwords, derived key from passwords, and then used asymmetric cryptography for authentication. Browsers could implement this as a type of password fields to get many of the benefits of passkeys, but where is the vendor lock-in in it.
Browsers could implement this as a type of password fields to get many of the benefits of passkeys, but where is the vendor lock-in in it.
There is no vendor lock-in, what are you even talking about. They're asymmetric key pairs, anyone can generate that. It's very very well-understood crypto.
Device attestation is explicitly vendor lock-in
No it isn't. They are assertions about the nature of the device that can't be tampered with; what you do with those attestations is entirely up to the Relying Party.
In practice, attestations are used primarily as a mechanism of feature detection.
In practice, attestations are used primarily as a mechanism of feature detection.
I only have been exposed to two forms of attestation so far. One has been the Austrian government ID which is used for vendor lock-in, the second has been an enterprise deployment which also was used to lock down the device to one specific vendor. I'm not sure what over forms of attestation exist, but both of the ones I have been exposed to are specifically used to ensure that only a range of very specific hardware devices can be used.
assertions about the nature of the device
These are only meaningfully assertions about the nature of the device if you keep an explicit allow-list
If I've understood correctly, Passkeys are impossible to phish. 1Password users can still be fooled into pasting their credentials into wrong places.
Mind you, I'm in the same boat as you.
1Password users can still be fooled into pasting their credentials into wrong places.
And that combination is especially rampant because 1P does not take autofill failure bug reports seriously, so they have conditioned their userbase that it's "just situation as usual" when the autofill dialog doesn't appear
I do appreciate that making anything that interacts with the web is a bottomless pit, but if Violentmonkey can add a badge on their extension for matching sites, I have every confidence that 1P could do so, too, if they cared to do so
Some sites are really going out of their way to break autofill — however the correct response is probably a toolbar button for choosing an account to copy to clipboard for the current site, regardless of how messed up the input situation is.
Sites that intentionally block copy/paste and autofill deserve a special place in hell.
Well, I just use autotype via xdotool if autofill does not seem to be working…
But yes, aiding and abetting cybercriminals (which anti-password-manager measures are, just like lobbying for encryption backdoor mandates) should be recognised as such.
1Password won't autofill passwords if the domain doesn't match. Copy/paste isn't the normal workflow and should raise some mental alarm bells.
Should, but if it did every time, phishing wouldn't be a thing.
Everyone makes a mistake, eventually.
Not a dumb post, I also use 1Password very extensively and I had the same question.
My biggest concern is somehow losing passkey data or being locked out, as described in the post. I never had this with passwords, but passkeys are something I don't have a good mental model for, beyond understanding public key crypto. (And even then, my mental model would be outdated within a year).
Think SSH public key auth but over the web in a complicated mess of Javascript and you basically have what webauthn/passkey's are all about.
So you get everything public key auth gets you: no MITM(provided you verified OOB somehow the public keys), no transfers of private key material, etc.
Is there anything in passkeys for me?
Not really. For most people in your situation things would realistically only become slightly more secure.
There are websites that I need 2FA where the 2nd FA is an SMS or number that will reach my mobile or even mobile notification that I have to click "Yes". Now, I can just use the passkey and avoid all that dance...
I fully agree with the critics of that awful "Continue with Touch ID" / "Other options" dialog. I won't be surprised if it was judged unlawful under EU's DMA as blatant gatekeeping.
However, if I can improve your daily routine: I discovered by accident that you don't have to click on "Other options" then "Security key" to use your Yubikey… you can touch your security key as soon as this dialog pops up and it works.
Still not discoverable, still a dark-ish pattern, but now you know :)
I have a security key with a PIN that I use as a second factor for a bank. Half the time the macOS dialog makes me enter the PIN, half the time it proceeds successfully without asking for the PIN. I have a hard time trusting what’s going on when stuff like this happens.
Software engineers don't understand consent, and it shows.
Maybe this is true but in this specific example I would bet a significant amount of money that the decision wasn't made by an engineer...
Consider a bad deed. When – under which conditions — should we consider responsible the one who orders a deed, but innocent the one who does the deed?
I am just disagreeing with the author's implication that an engineer was given a choice in how to design this feature and chose to do it this way. To the extent that you believe the result is bad I would agree that everyone involved in the implementation shares some responsibility.
Ah right, casting responsibility more broadly. That feels right, when big companies do dark patterns there are almost certainly more people involved besides the programmer. Sorry for my initial misunderstanding, I thought you were giving the engineer a pass for following orders.
I've seen software engineers blamed for color choices, bad documentation (in end-user products, not API docs), limitations that are a result of contractual obligations, marketing language...
e: To be clear, all of these were in products from companies that are large enough to have designers, docs people, and so on, not single-person things.
Every time I see a passkey enthusiast I ask them what happens if I lose my device.
Then they say passkeys are supposed to be used together with other authentication methods and you can use those to recover access to your account.
I guess you can frame it in a way that makes sense, but there is kind of a motte-and-bailey happening with the entire passkey discourse.
I am a passkey enthusiast.
I have multiple passkeys (multiple yubikeys). If I lose one, I still have access.
That said, it's also fine to use other authentication methods to do recovery on those accounts. The benefit is that if you use passkeys for 95% of your authentications, then those 95% times aren't suspectible to the credential phishing risks that passwords are.
The relevant risk is that each time you enter a password, that's an opportunity for phishing. Each time that's removed, that's a win.
I don't get the appeal of yubikeys. When I had one, the documentation around it was so sparse and bare that I don't think anybody other than the most hardcore enthusiast could really leverage them in any way.
I don't consider them to be functional in the wide sense.
I agree for Yubikey PIV/OATH/PGP.
Is this true of the Yubikey FIDO keys, i.e. the cheap $20 ones?
Yubikey appeals to me because non-exportable credentials and touch-to-auth reduces a lot of blast radius for local exploits.
I suppose they appeal to companies rolling these out to non-techies for similar reasons, though they have internal departments to help with setup and integration.
All that said, passkeys don't rely on physical fobs. I don't think my family will bother with physical fobs. My family instead are happy to rely on browser provided password management.
My family instead are happy to rely on browser provided password management.
Your family will be not so happy (not to mention you) when they have to call you when some fundamental error removes their browser provided password management.
Then they say passkeys are supposed to be used together with other authentication methods and you can use those to recover access to your account.
Never once read that from someone advocating for passkeys. Usual answer from my pov would be to have more than one device. Which is inherently true with the big platforms, them syncing with the cloud and all the devices you own.
I thought the majority of the world only had one device: their phone.
And of those that do have multiple devices most can already use a password manager and are paying enough attention to escape phishing.
I know literally no one who doesn't have at least either a tablet or laptop. And I'm working in EMS, so no tech bubble bias here. But even with just a phone, the second device would simply be the cloud.
And of those that do have multiple devices most can already use a password manager and are paying enough attention to escape phishing.
So everyone owning a gaming pc or a laptop for „browsing the web and writing emails“ is versed in cyber security?
How does using the cloud someone else's computer work in this case without trusting that someone else with my accounts? If I can restore them without access to my private keys or a password, how do they not just have access to my passkeys?
Its e2e, so it can’t be restored without password (for Apple at least, don’t know the others). But that was not the question in the first place…
Every time I see a password enthusiast I ask them what happens if I lose my password.
Then they say passwords are supposed to be used together with other authentication methods and you can use those to recover access to your account.
I guess you can frame it in a way that makes sense, but there is a kind of a motte-and-bailey happening with the entire password discourse.
Every time I see a password enthusiast I ask them what happens if I lose my password.
Is this still a realistic question with password managers, where you only have to recall one master password?
Conversely, if you're unable to recall a single password (drunk, concussed, dementia, etc), perhaps you should not be doing secure things, and should be locked out?
(Yes, I know most people still don't use a password manager.)
My point is just that "what if I lose it and there's no account recovery process/I can't do account recovery for some reason" is always presented as if it's a failure mode unique to passkeys, when it's not unique to passkeys.
You can forget a password and if there's no account recovery process you're just as locked out as you'd be with any other type of credential. Or to go with some of the more involved hypotheticals, you could forget your email password and lose the only device currently signed in to your account, and thus be unable to complete email-based account recovery.
The single master password unlocks a store. You could lose that store if it’s only on a single device. Doesn’t matter if you store passkeys or passwords in it.
Yeah, but backing up stores is an unrelated issue to forgetting a password. How many password managers don't sync to multiple devices or server backups?
I don't know about FOSS password managers, but 1Password, at least, copies the encrypted store to all my devices, with a server backup.
ubernostrum’s point is that this is no different between passwords and passkeys.
Yes, but what I was trying to point out is we need to distinguish between "possible to lose" and "likely to lose".
I've remembered a small set of passwords over decades now, but have already run into two situations where passkeys logins have ceased working properly less than a year after creation. I'm not sure why, but from a practical standpoint, those passkeys are "lost" to me.
The majority of people in the world don't use third-party password managers and never will.
I guess you agree with me that passkeys are not an improvement over passwords at all then?
Passkeys are far more resistant to phishing than passwords, which is a significant improvement.
So, no, I do not agree with you that “passkeys are not an improvement over passwords at all”.
From a user perspective, a passkey is simply a password that the user does not (and cannot) create, that the user cannot view or type in, that the user is not forced to remember, and that the user is not forced to change every few months. With a good password manager (which handles password creation and even rotation), the difference between passwords and passkeys (to the user) will be minor, with the important different being that the user cannot directly access/view (and thus potentially share -- inadvertently or otherwise) their passkeys.
and thus potentially share -- inadvertently or otherwise
This is it.
Authentication mechanisms have to be strong enough such that least the median (and possibly the 99th percentile) user is not hacked due to poor credentials management.
A user that uses a password manager isn't the risk. It's the user that does password reuse, and, like all of us, are phish-prone.
They are why sites are increasingly requiring TOTP or FIDO2 as a second factor.
That's a crappy login experience, as we all know.
Passkeys are an attempt to get the security benefits of a diligent password manager user, but available to anyone with a smartphone, without them thinking about it.
(They also happen to enable FIDO fobs, which appeals to me.)
I get the vision, I just think it's unrealistic. Heck, I'm a diligent password manager user and when I tried to use passkeys I still managed to mess up so badly I almost locked myself out of an account, had to use my recovery code.
Passkeys are really really complicated in practice, and so I fear the only way the median user will be able to use them is to let big tech handle all of it. Which leads to an endgame where Apple or Microsoft can lock people out of all of their online accounts simultaneously, with no recourse. I'm not sure whether that's better or worse than the phishing problems of today.
I get the vision, I just think it's unrealistic. [...] I'm not sure whether that's better or worse than the phishing problems of today.
I agree there's tradeoffs risk, portability/lockin, and UX.
I ask with genuine curiosity: do those tradeoffs make it unrealistic? Or is it just that you would make the tradeoff in a different direction?
Whenever I am on tech support duty, I notice that people set up passkeys even though they don't know what they are. The os prompts them to.
This really sucks when people are trying to, say, log into a different microsoft account and it simply won't let them because it keeps ramming the existing passkey down the system. If you click "use another passkey" it doesn't work.
if I lost access to my Credential Manager what is the recovery path?
Apple's MFA setup is already such that if I were to lose access to all my devices and don't have an emergency contact setup, there is realistically no recovery path maybe not even with recovery codes.
Even if there is a recovery path, if you've ever been in these dark nooks of the onboarding process, it's all poorly tested and a miracle if it works at all. Add to that: There is no real (human) support conveniently available either.z
Beyond that we start to face challenges.
I'd say yes, that the biggest problem here is that the technology is entirely immaterial. That makes it very difficult to teach to people and effectively a form of "magic". This is also something that's such a fundamental flaw of stitching that it will be more or less impossible to fix that at this point.
I can print that out and it would be annoying but I guess I could type it back in. But it's something I can still conceptualise. I can't even print it out and keep a copy in case of a disaster.
This is super important. You can't print out Passkeys?!?
If this confuses security engineers, what about people in other areas with different areas of expertise?
Zero chance. None at all. They'll have to go back to losing accounts and creating new ones every 6-12 months like many of my family members have done.
Software engineers don't understand consent, and it shows.
I would add a classic bit of Papanek: “There are professions more harmful than industrial design, but only a very few.”
access to education about Passkeys
Does such a thing exist?
If you do choose to use a platform Passkey provider, you can "emulate" this backup ability by using the credential export function to another Passkey provider, and then do the backups from there.
They aren't shipping backup natively in the tools themselves???
This is super important. You can't print out Passkeys?!?
A passkey is just a large integer or two, i.e. a private key. Most users will have no way of accessing the raw bytes of their passkeys, because the various "managers" of passkeys don't show (or provide other access to) the passkey values.
If you lose a passkey, there should generally be a means of establishing a new passkey for the account, e.g. the old fashioned 2fa (or more) model. This is how most sites work for me today, but I won't claim that all do this well.
In other words, passkeys are intended to be lose-able, i.e. never recovered (or recoverable). In the consumer space, passkeys are intended to be a safe convenience, not an irreplaceable key like you have with a safe deposit box.
passkeys are intended to be a safe convenience, not an irreplaceable key
This is interesting because I didn't read it like this at all.
As another message said, you can think of it analogous to an ssh key. The server has enough info (the public key) to verify that it's you without you using a login name / password. But you can still log in from another machine that doesn't have the same ssh keys, by first logging in with the appropriate login name / password, then registering your new machine's ssh key for subsequent connection use. (I generally do NOT allow this on production servers, since there are a lot of issues with login/password, but it causes a lot more work for ops to manage the ssh keys.)
But doesn't the argument "you can't leak your credentials" depend on there not being any leakable (i.e. username/password) credentials? As long as these are there, you could still be tricked into giving them up.
I'm not sure what you're asking. The question isn't making sense to me, but that may be because I'm not an expert.
Have you used SSH? Have you used it with SSH keys, instead of login name and password? Do you like the experience of using SSH keys? That's what passkeys should give you, but with a bit better security for the local management of the passkeys.
I think a lot of people see passkeys as a complete replacement for username and password, the way OAuth replaces it, instead of just as a time-saving convenience for subsequent logins. Its fine for that!
a lot of people see passkeys as a complete replacement for username and password
If they say: "You can't be fished anymore.", wouldn't that require removing username/passwords altogether?
the way OAuth replaces it
OAuth doesn't really replace it though since most sites will have you set both e-mails and passwords after your social login.
Yes, and I have no doubt that some sites / apps out there will require passkeys, i.e. not as an option but as "the only way". So far my experience has been that passkeys have been an additional option, not a replacement, but you know that there are at least a few overly zealous (and/or fad-following) developers out there who will take this too far. It's inevitable, and predictable. But for the most part, I see the move to add passkey support to be a net positive.
One major regression is login experience effort and speed . What used to be a single screen and predictable credential is now 4-6 credentials (email , 3+sso, various passkey, various 2fa) and 3-5 screens just to log in.
Who thinks this makes anyone safe ? It was hard enough to remember a password . Now you have to remember : site , sso vendor , passkey / credential vendor , 2fa contact and more
You can’t increase security while bankrupting usability like this. People will just workaround , lose trust and breach their credentials .
I use passkeys for a bunch of sites. I click "Sign In", and get a biometric prompt to unlock and use passkey, and then I'm signed in. It's as fast as password-only auth, and faster than password + TOTP or password + USB security key.
You’re right this is the ideal, but most sites have a couple screens first , device confirmation afterward. And the issue is inconsistency. Are users expected to understand the bespoke UI for each site . Some start with username , sso, and have other steps before logging in.
The regression is about the broad inconsistency of experiences and how few sites support the ideal case – the inconsistency and complexity outweighs the few improvements like your case
but most sites have a couple screens first , device confirmation afterward
Passkey first stops being appealing when you have more than one user signing on one device. It's a nightmare when you have a family and kids accounts.
Why? It just asks which one to use. Besides, each user of the device should have their own device account with it's own passkey store anyways (if possible, looking at iPads…)
Why? It just asks which one to use.
On the device there are usually just the passkeys of the primary user. Some might not even allow more than on passkey (eg: Apple's iCloud).
Besides, each user of the device should have their own device
Even if you are a family where every child has their own device, you end up having to authenticate with a parent's account half the time to give permission for stuff. And I do not want my child to have access to my or my wife's account on their device. So you end up in a situation where you need to temporary authenticate with another account on a device which forces you down a passkey first flow.
I can give you a whole range of applications which make this incredible painful today, even though they actually primarily cater to kids and require parents to also authenticate.
I guess the iCloud flow also doesn’t let you use a passkey from a different device like in Safari? I like that for temporary logins on another device.
Last time I was in the situation where a passkey was bound that auto signed in, it just brings up the touch-id thing when it finds a passkey that is already known. If there is a way to present a different passkey, then it was not obvious to me how I would provide it.
Yeah, it’s not at all obvious. One has to dismiss this first modal and tap on the key icon above the keyboard to choose a different passkey (or username/password combo).
This is a corporate issue–these apps are all implementing SSO because they want that juicy, lucrative, corporate contract. And they end up having multiple screens for SSO because that's usually the least confusing way to do it.
Ironically, if they dropped that SSO stuff and just implemented passkeys, login would be a single button click on the first page: https://x.com/yawaramin/status/1956531278552965234
i see it as a user agent issue as well. along with the low level API for webauthn, user agent / browser / mobile OS could provide seamless & native passkey integration
One major regression is login experience effort and speed . What used to be a single screen and predictable credential is now 4-6 credentials (email , 3+sso, various passkey, various 2fa) and 3-5 screens just to log in.
Serious technical question: What does this have to do with passkeys?
It sounds like you're in an environment with some horrible software that you are being forced to use. Any vendor names that you can share that we can subsequently avoid like the plague?
every website that was once a single screen for username + password is now 3-5 screens : enter username, choose provider, enter credential, enter TOTP / 2FA, confirm browser -- plus all of the invariants during this process.
Every screen you add is a doubling of the number of failure modes .
It used to be "did I forget my password" and now it's " did I forget my password? my SSO provider? my 2FA app? my passkey device?" .
2^3 or 2^4 combinations that all have to be remembered and entered correctly to log in.
And none of this matters at all to people. They want to check mail, buy goods, buy flights, send messages.
But that’s not the fault of passkeys, but those websites. Look at GitHub how it should be: clicking on the login page, it prompts for passkey. If that is successful, you’re logged in. If your device has no passkey, there is no prompt for it, and you can enter user/pw, login with apple/google, or click a link to use a passkey that wasn’t auto discovered instead.
Done correctly like that, it’s a strict simplification, while having the same or higher security. So blame the websites, not the standard.
What does this have to do with passkeys?
Passkeys add another unusable technology to an already stacked field.
unusable
You keep using that word; I do not think it means what you think it means.
It means "lacking in usability".
unusable ... It means "lacking in usability".
You might be coming to English as a second language. "Unusable" doesn't mean "lacking" -- it means that something cannot be used. It is quite the boolean.
That’s not it. Usability is a spectrum and there’s no absolute “unusable” so it’s fair to call things on one side of the spectrum unusable.
It is somewhat commonly used in UX land, eg. https://podcast.theunusable.com/
you can't possibly be this dense.
you can't possibly be this dense.
When I say that something is "unusable", I mean that it cannot be used. It is not fit for purpose. It does not do what it says on the tin.
So when someone says that something is "unusable", I have to assume that it is broken. That it does not work. That it is has kicked the bucket, shuffled off its mortal coil, run down the curtain and joined the bleeding choir invisible.
This isn't about being "dense" (incivility noted). This is about words having distinct meanings, and respecting that communication works precisely because humans agree on the meanings of words. I'll defer to the dictionary: adjective, 1. That cannot be used. "unusable byproducts." 2. Not fit for use. "unusable files on corrupted disks." 3. Not usable.
Here's a case with Walmart.com .
"passkeys enable simpler login" -- nothing is simpler than username + password. And if none of the vendors are implementing them properly, that's an API problem.
I shouldn't need 3 devices and 4 screens to log in.
This is an excellent example of horrible UX. I am on the same page with you: web sites should be secure and usable. I'm looking at walmart.com and I see that they now have passkey as an option, but I have not set this up (thankfully, in this case) so I will avoid switching to it based on your experience.
Now let's talk about how it should work:
To be clear, I've implemented the back end challenge mechanisms for various auth schemes, but I suck at the front end work, so I'm likely missing some details for how to best achieve the seamlessness that I know is possible (from my own experiences using websites that don't suck).
Totally agreed with the article. Passwords feel like something I have, it’s “mine”. I can see them and move them around as I please.
Passkeys are these weird invisible things I have to blindly trust, and the groups holding them are some of the most blatantly untrustworthy around.
I like the idea of asymmetric encryption but let me see the keys !!!
I'm looking at a passkey private key right now, in KeePass. If you want to own the keys, you can just use a manager that lets you mess with the keys.
Oh cool!, I might start doing that then. It'd certainly be faster than SMS 2 factor every single time.
I still don't think I can use it by itself, since there are times I like to log in to websites on computers I don't control, like my sister's laptop or something, and its inconvenient to have to download a password manager onto it. It's inconvenient that I have to get a new manager in general, i like firefox's just fine.
& I still can't recommend passkeys for normal people using the UI flows heavily pushed, where the keys are tied to one OS's ecosystem.
TLS certificates work the same way but you don't see people demanding to export their browser's private keys. I think the hysteria over passkeys not being 'mine' is way overblown.
By the way, the fact that passwords are 'mine' also allows me to be tricked into entering them into malicious websites. Passkeys make this a non-issue.
It's easy enough to copy a TLS certificate and its private key from one device to another. When passkeys let me move them around with Ctrl+C and Ctrl+V, we can make this comparison, but I'm reasonably confident that they never will, by design.
Really? You can easily copy a browser's TLS private keys from one device to another?
But that's not even my point anyway. My point is, why would you even want to? These keypairs don't even matter, you can just generate new ones on new devices. Coming back to my original point–there's no plausible vendor lock-in. Any time you're on a new device, you just log in to the account with your email and generate a new passkey for the account.
I’m not quite sure I get the TLS connection, since that’s not being used for authentication.
& idk, I just really don’t trust that I will always have access to my passkeys if they can only be stored on someone else’s cloud or hardware I can’t access (tpm). Seems like a lot of control to be giving up to companies that have already proved themselves untrustworthy.
TLS is being used for authentication, just at a different layer. And just like TLS certs, you can just get a new passkey on a new device. You don't need the passkey from your old device. Each passkey is disposable.
the groups holding them
They're stored locally. If they are stored "in the cloud", they're only transmitted and stored in an encrypted from (using encryption that only your devices or you have a key for) in a manner than cannot be decrypted by the cloud provider.
I like the idea of asymmetric encryption but let me see the keys !!!
Outside of debugging, I'm not sure of the "why" of this?
It's kind of like saying "I like my computer booting when it turns on, but show me the bytes of the firmware code." If you're not debugging the firmware (or doing a security analysis), seeing the bytes has no value. And in the case of crypto keys, seeing the bytes is actually worse than that, since it implies leakable (or worse, phishable) data. The best way to never leak private keys is to never have access to them 🤷♂️
The way I understand it, they’re stored in the TPM/SecureEnclave etc, on a cloud, or otherwise on something I do not control. I can only use passkeys so long as the code there that I cannot control still agrees with me.
If it was something I could control, then by definition, I would be able to see the keys. (Optionally. If I wanted to. There’s no real need to ofc, like you say). The only way to prevent this would be to take control from me.
If, for example, I got locked out of my Apple keychain, what could I do? Passwords at least I could have written down on paper that I definitely 100% can’t lose access to.
& I see firmware pretty similarly actually. I want the option to unlock the bootloader even if that’s a security risk, because it’s my computer and the alternative is that the hardware manufacturer gets to decide what happens instead.
One trick to mitigate the vendor lock-in is to have multiple passkeys using different providers. The article touches on storing and backing up, which is great, but nobody stops us from just having as many keys as needed.
This becomes an M * N problem, which we morally ought to turn into an M + N problem if possible.
sure, but then I have a bunch of keys that are functionally identifiers for me floating around outside of my constant supervision.
I need to have them with me periodically to add them to my accounts (and remember to do so).
And I've seen exactly 2 implementations where they assume you might have more than a single passkey- normally the option is super hidden or doesn't even exist to add a second or third passkey.
Passkeys have been around for like a handful of years now. Passwords have been around for decades. The kinks are being worked out, give it a minute.
That’s not how it works.
Every site that supports passkeys are pushing it fairly hard.
UX warts like that will kill it in its infancy if its not thought through from a user perspective.
For many sites, their alternative is that they push TOTP and/or FIDO2 as a second factor, and that's a worse experience.
While I agree, this runs into an issue of education. To the extent that people think of passkeys like passwords and not house keys, they may assume they can't have more than one. This situation is not helped by passkey vendors trying to lock you in to their platform.
You're supposed to have multiple passkeys for every account that uses passkeys? How would I ever manage that?
The general idea is that if you use, say, a laptop and a phone and a tablet, each of them could have its own passkey store and its own on-device passkey for a given account.
This does not have to be as difficult as you make it out to be. The first time you sign in with non-passkey auth on a new device, the site can offer to store a passkey on that device, and that’s that.
But if they are all Apple devices wouldn't these sync and it would be the same passkey?
What I described is what I understand the original vision of passkeys to be. Cloud syncing by vendors like Apple and Google, and the idea that you should only ever have one passkey per site, came later.
And I do wonder if the cloud syncing turns out to be an anti-feature in that sense: one of the neat things about passkeys is that you can have different passkeys for the same site on different devices, and it's not bad or wrong to do so. That opens up some interesting potential security features, like being able to revoke a specific device's passkey if you lose access to it. It also, I think, becomes a more intuitive user experience if presented with the right framing: "Sign in with your phone" in the same way people are used to "Sign in with..." various OAuth providers.
If they are all Apple devices, and they all sync to the same iCloud account, then your question doesn't make sense in the first place because you wouldn't even have multiple passkeys for every account, you'd just have the synced passkey managed by your iCloud account.
OP said you should have multiple passkeys.
Are you talking about this:
mostly the large problem sites have now finally allowed you to enrol multiple Passkeys.
?
That's not saying you should have multiple passkeys, it's saying account providers should allow you to have multiple passkeys.
What I would add is, you should have as many passkeys as you need. Using new device? Add a passkey. It's a shared account on the device? Then obviously don't add the passkey. Passkeys assume you have your own account on a device.
I would say the general idea is that users have a synced store of passkeys that’s available on all their devices.
Yes, you can use Apple's system and 1Password. Just add a passkey on both. I do this for passwords too. Usually if I need to create a new password, I do it in 1Password and then the next time I log in, Apple offers to save it too. I don't fully trust either to never lock me out, so I'm sticking with this solution for a while.
I was entirely unable to enroll 1password's passkey for my apple account. If there is a way, I have not found it. I'm also somewhat curious what apple uses to lock this down because it does not seem to use attestations.
As far as I know, the Apple account passkey implementation is locked completely to Apple, and they don't have a provision for creating a passkey anywhere other than on iOS/macOS devices. It's infuriating.
OK so the main problem discussed in this post is vendor lock-in? Personally, I don't think that's a problem if your account provider allows multiple passkeys per account (which they really should, because that's the correct way to do it) and allows you to log in with an emailed magic link on any device where you don't have a passkey, then automatically registers a passkey. Now you are completely device-agnostic.
I agree . Problem #1 is usability , #2 is maintainability and vendor lock in would be #5 or or lower .
We’ve added so many more dimensions to logging in that it’s very difficult to match the credential to the app . And the multi step login experience is an insecure tight rope experience trying to get in. Always at the most inconvenient and urgent time too
I'd like to add that backing up a credential manager should also not be something that users have to learn about and seek out themselves, it should "come standard".
My own pwm.sequentialread.com constantly replicates to 3 places, localstorage in browser, server filesystem, and backblaze. And then I save the passphrase to decrypt it in other places besides brain. Takes zero maintenance and I can be confident I'll never lose it.
Passkeys are Big Tech nonsense designed to make us dependent on our phones, allowing corporations to continue to shunt responsibility for their own screwups onto users.
Passwords are totally, 100% fine. Passwords and a password manager give the user autonomy and flexibility. If the situation was as disasterous as the Big Tech fearmongers say it is, literally nothing in the world would work. But here we are, living in a world built on passwords with some MFA now and then (if it's warranted, and in many cases, it's not).
Microsoft, Google, Apples, and the rest? They see all the data breaches in an aggregate that is disconnected from any individual's reality. Their concern is risk mitigation at scale. They don't care about users, not really. All passkeys do is introduce a drastic new failure mode for the end-user.
They see all the data breaches in an aggregate
More importantly, they are allowed to completely ignore the damage from account lock-outs, even the ones they cause themselves without any recourse and for capricious reasons.