Yep, Passkeys Still Have Problems
Key topics
The debate around passkeys rages on, with many commenters weighing in on their usability and limitations. While some argue that passkeys are over-engineered and too complicated for most users, others point out that features like FIDO Cross-Device Authentication were designed to address specific use cases, such as accessing personal services from locked-down corporate machines. The discussion highlights the tension between security and convenience, with some commenters nostalgic for simpler authentication methods like TOTP, while others appreciate the control it offers. As the conversation unfolds, it becomes clear that passkeys still have a long way to go in terms of user-friendliness and flexibility.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
10m
Peak period
71
6-12h
Avg / period
16
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 17, 2025 at 8:12 AM EST
17 days ago
Step 01 - 02First comment
Dec 17, 2025 at 8:22 AM EST
10m after posting
Step 02 - 03Peak activity
71 comments in 6-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 20, 2025 at 8:44 PM EST
14 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Succumbing to lock-in can smooth some (but not all) rough edges.
TOTP for the win --- it's the simpler practical alternative.
https://chromewebstore.google.com/detail/lazyotp/eoihmklnjkn...
I also think there's still an enormous ignorance from passkey devs that lots of people want to occasionally log into personal services from locked down corporate machines, and the flow to deal this is at best terrible but more often non-existent, and developers with typically enhanced privileges just aren't able to conceive how difficult this is.
Corporate installs disable all USB functionality, and remove the ability to sync profiles? Something like that?
This is usually a bad idea, and is sometimes expressly forbidden.
But. more generally, there must be a flow for accessing your account when the passkey is not available, and possibly cannot be recovered.
Logged into Passkeys.io on my phone, and created a passkey.
Then tried to log in to it on my Windows desktop, using the "With my phone" option. First time around it failed to connect to my phone. Future times it connected, but told me that the phone had no appropriate passkeys on it. At which point I gave up.
On the other hand, I thought I had fully researched how passkeys work and literally never came across it.
So it kind of just continues to support my concern that passkeys are just too complicated to understand. If I'm at another device I need to log into, I would have just assumed I couldn't.
If there is no passkey on the local device, a QR code will appear which you can scan with your phone or tablet, and use the passkey for the account from that device. It just kind of happens, typically without the user having to do anything special.
I will say though, corporate devices can be a bit of a wildcard as they are usually configured and locked down for a specific purpose. But the cross-device flow is generally not blocked by organizations.
What I'm saying is, I thought I had the right mental model of how passkeys work, after researching them, and that mental model told me you wouldn't be able to log in on a different device without going through a whole procedure to set up a new passkey, which you wouldn't want to do for something temporary.
The mental complexity is just too much for me to trust that if I adopt them, they'll work when I need them. The fact that I got this thing wrong means there's probably other things I'm still getting wrong.
I understand passwords and password managers and even 2FA. I feel like I can plan how to use them right so it all works and I don't need to worry about not being able to access my accounts. I just don't have that confidence with passkeys.
1. Start to login to the site.
2. When it gets to the point that you would choose to use a passkey if you were logging in at home, there should be some option that lets you say you want to use a passkey on another device. You can use that to tell it you want to use a passkey that is on your phone.
3. It gives you a QR code to scan with the phone, and then you complete the login using the passkey manager on the phone.
The government can, though. I’m not sure if there’s any existing laws pertaining to transfer of or access to general accounts after death (as opposed to bank accounts which I’m pretty sure there are laws about).
My will says that my executor can access my accounts which alleviates Apple from legal risk if they do grant access but I’m pretty sure they are not obligated to do so.
I wrote about it here: https://digitalseams.com/blog/what-happens-to-your-online-ac...
Whatever process a vendor requires someone to go through in order to gain access to someone's account when they pass away remains the same whether the user previously used a password or a passkey to login.
Are you aware of any vendor that actually does have differing policies based on the account's login credential type? I'm not aware of any.
The only one who can lock me out of my relationship with e.g. HN is HN.
With passkeys:
Now I can be locked out by HN or by the passkey provider.
Sure I could use a local passkey provider, but the protocol provides a way for the site to enforce a whitelist of passkey providers, so it's not clear that would be an option. Particularly for businesses like banks which tend to adopt an approach of "if a security restriction is possible, it should be applied". Or even just the typical tech PM perspective of "we want to include logos for the log in with X, and I think more than 5 logos is ugly so let's just whitelist Lastpass, 1password, Google, Microsoft and apple and be done with it"
If I want to move a passkey out of my Apple keychain, last I heard the answer is to just make a new passkey. The important part of the secret is 100% under their control. It makes me very squeamish
If someone passes away, their family members can use the Emergency Kit to gain access to and use all their credentials - including their passkeys.
(The Emergency Kit is also intended to allow your to recover your passkeys and other credentials in the event you forget your master passphrase or lose all your devices.)
[1] https://support.1password.com/emergency-kit/
I don't want a passkey on my logins but there is no way to disable this prompt on the 3 websites that constantly annoy me for them.
Drives me batty. The company I work for is already paying you for the service I'm using. We use SSO for EVERYTHING, I've already 2FA Authenticated the login, and even if I set up a passkey I will still have to 2FA the login.
I don't use these sites in any personal capacity, and I would never use a site that harasses me in any way if I was not absolutely required to in order to earn a paycheck.
You're not going to get any money out of me, why are you torturing me?
If he can't get his account back in any reasonable amount of time what chance do I have?
(I see I missed a big HN discussion on this: https://news.ycombinator.com/item?id=46252114 - 1038 comments)
Until service providers are no longer allowed to:
I'll continue to stick to plain old boring password + TOTP. I fully understand the security trade-offs like phishing resistance but password + TOTP is secure enough for me.(2) I understand you don't like the user experience. But to make a technical clarification: requiring a user action to prove there's a human involved in the login action (e.g. by clicking a button in UI or requiring Touch ID) does not necessarily mean there's another factor involved at all (MFA). What you are describing is more of a "liveness check" than a separate factor/separate credential.
That said, if you have a mac with a fingerprint scanner they sure are very convenient option.
And don't get me started on terrible vendors like Rippling that only support a single passkey! Madness.
The default, built-for-the-masses implementation of passkeys is called "synced passkeys". They are designed to sync between all your enrolled devices, ideally using end-to-end encryption.
You authenticate with whatever device you happen to be using at the time - phone, tablet, laptop, desktop - doesn't matter. If you lose one, you replace that device and re-enroll - then all your passkeys magically re-appear on the new device.
If you're cross-platform, modern password managers work across ecosystems - for example, 1Password syncs passkeys between Mac, Windows, iOS, Android, and Linux. If you're all-in on Apple, their native passkey implementation syncs passkeys between all your Apple devices. I thought Google and Microsoft do something similar now.
It's a real mystery why people believe passkeys have to be stored on your phone only.
Passwords I can bring anywhere.
Apple's native passkey implementation doesn't require doesn't require you to install extra software, and the passkeys sync by default. I thought Google's and Microsoft's were similar - but I haven't tried them.
> And even if you do, it’s discouraged
Really? Where is it discouraged? I thought synced passkeys are intended as the solution for consumers.
> the spec is allowed to deny you access
Yeah but I thought that's for enterprise use cases, not consumer. E.g. employers that want to enforce device type restrictions on their employees.
& I think it is mostly being used for enterprises for now ,but much like TPM and remote attestation running on “my” computer, I don’t like that it’s an option
Why do you say that? There are billions of synced passkeys being used by users with some of the largest sites and services in the world.
To my credit I think yubikey uses the term that way and webauthn has a different definition but in the context of passkeys you’re right.
The security property you care about is that the plaintext key is only ever handled transiently within the secure enclave (for proof of possession during authentication).
That doesn’t preclude syncing or backing up the encrypted key via a cloud service.
How do the decryption keys for the encrypted passkeys get shared between devices?
I wasn't referring to hardware keys (like YubiKeys), but rather on-device SEs, TEEs, or TPMs.
Also I said "_protecting_ a key using the secure enclave", a bit of a sleight of hand :-)
By that I mean a key that is wrapped (encrypted) using a parent key stored in the secure enclave. The key itself is not stored in the SE. But since it is wrapped using a parent key that is stored in the SE, that means it can only be decrypted by the SE. I believe this is basically how iCloud Keychain works, for example.
Digging into this further, it looks like I might have been wrong to imply that a credential manager app can instruct the SE itself to perform the proof of possession calculations used in passkey authentication using a private key that is "protected" in this sense. Maybe when the app asks the SE to decrypt the passkey private key, the SE returns the passkey private key in plaintext and the app itself performs the proof of possession calculation transiently outside the SE. But I'm not sure, and I'd love to know.
> How do the decryption keys for the encrypted passkeys get shared between devices?
They get established as part of the device enrolment process. I suspect this simply adds another layer to the key hierarchy, so that your passkey private keys are encrypted under a sync key (parent) which is encrypted under a SE key (grandparent).
If that's the case then you can still claim that your passkeys are "protected by the SE" since they are encrypted at rest and cannot be decrypted anywhere except by the SEs of your enrolled devices.
Stored in an authenticator/credential manager in general, not specific to a security key, secure enclave, or TPM.
For the machines you don't control, such as your employer Mac, that's a special case. In theory you can use "FIDO Cross-Device Authentication", which is a passkey flow specifically for authenticating on one device using a passkey stored on a different device, and involves scanning a QR code.
I've never tried this though. Personally I tend to avoid mixing personal stuff with work stuff, so the problem rarely arises.
(quoting https://news.ycombinator.com/newsguidelines.html)
1. Passkey prompts asking if I want to use a phone or security key when I only have one (or neither!) registered. The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered.
2. Passkeys should have had the portability and flexibility that ssh keys have from the start. Making it so your grandparents can use public key cryptography and gain a significant advantage in securing their accounts in a user friendly manner should have been the priority. Seems like vendor lock-in was the goal from the start.
Exactly. The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. You can go from one passkey vendor to another, but you're always locked in to one passkey vendor or another.
Any credential system that makes it impossible to write something down on a piece of paper, take it to a new computer, and login to a website is just a gateway to vendor lock-in. You can manually manage your own ssh keys but for some reason not your passkeys.
As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
But again, kicking the can down the road.
I’ll accept that the attestation parts of the protocol may have had some ulterior motives (though I’m skeptical), but having to reveal your credential to the verifying party is the entire benefit of passkeys and hugely important to stop phishing. I think it’s disingenuous to argue that this is somehow unnecessary.
I think you misunderstood what I was talking about. The credential exchange protocol is for exporting passkeys from one credentials manager and importing them into another credentials manager. It has nothing to do with the relying party.
For the general public, they already rely on either Google or Apple for pretty much all of their digital life. Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
I don't want to use a Yubikey. It's a pain in the butt. I just want to use my Mac, with no more damn dongles.
Keepass is a vendor, and one who doesn't even have a Safari extension.
> Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
I didn't say there was anything wrong with extending this to passkeys. The problem is the lock-in, e.g., Safari requires iCloud keychain for passkeys, but not for passwords. And there is no plaintext export/import, unlike with passwords.
No, this is a passkeys problem. Safari does not force lock-in of passwords.
Why in the world would I want to ditch my web browser just to use passkeys? I'd rather ditch passkeys.
Repeating this doesn’t make it true. https://developer.apple.com/documentation/authenticationserv...
All of the 3rd party credential managers I’ve used that support passkeys work with safari, and through the APIs that Apple offers the credential managers you can even pick your default CM and never think about iCloud again…
I've already addressed this pedantry: https://news.ycombinator.com/item?id=46304137
This is not true - Safari also supports passkeys managed by third-party password managers.
I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS which work seamlessly with my passkeys.
I think you know what I meant and are just being pedantic here for no good reason.
Do you think I'm unaware of 1Password? I don't want to use 1Password any more than I want to use iCloud Keychain.
Technically, pendantically, Safari "supports" anything that third-party Safari extensions support. I'm a Safari extension developer myself. But this is totally different from how Safari supports the use of passwords, which is all built in, requires no third-party software, can be local-only, allows plaintext export/import, etc.
[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
Not sure how stating that my (an individual) opinions on a topic are evolving is interpreted as "threatened the KeypassXC developers".
If you've been following along, you'll have seen that I am actually one of the biggest advocates of the open passkey ecosystem, and have been working really hard to make sure all credential managers have a level playing field.
Always happy to chat directly if you have concerns!
1. https://fidoalliance.org/specs/cx/cxf-v1.0-ps-20250814.html#...
Care to cite this statement?
> As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.
You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
>> There is no passkey certification process
> This is currently being defined and is almost complete.
>> no signed stamp of approval from on high
> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
[0] https://github.com/keepassxreboot/keepassxc/issues/10406#iss...
But I'll respond.
> Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID.
AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.
> You can use any credential manager you choose.
Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.
At that point, those banks/services would enforce vendor lock-in on me.
Yes, literally from you: "Passkeys should never be allowed to be exported in clear text." https://github.com/keepassxreboot/keepassxc/issues/10407 Also, "You absolutely should be preventing users from being able to copy a private key!"
> You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
But I want to use Apple Passwords.
> But I want to use Apple Passwords.
You're choosing to use an app that doesn't meet your needs, when there are numerous apps out there that do meet your needs. I'm not sure how anyone is supposed to solve that for you.
I am using an app that meets my needs. I don't need passkeys. It's just other people telling me that I need passkeys.
Years and years of security incidents with consumer data show that this is a really bad idea.
At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key.
What should happen if it does not?
It feels like this stated minimum is not your actual minimum.
Consider for example a macOS user keychain. The keychain is encrypted on disk with a user-selected password. But once you unlock the keychain with the password, you can copy and paste passwords in clear text. The keychain is not a black hole where nothing ever escapes. And I have no objection to this setup; in fact it's my current setup.
So when you say copy and paste of passkeys in clear text is not a good idea, there's nothing inherent to encrypting credentials with a user key that prevents such copy and paste. There would have to be some additional restriction.
A tech-savvy relative of such a user should help them generate rescue codes, write them on a piece of paper, and store them along with all other important documents. Ideally the paper should also read: "Call me before using any of these codes! <phone number>."
a key based approach is great. Knowing (the passphrase) and Having (the key) is a good way to authenticate.
A passkey basically offloads user identification to the OS (especially a mobile OS). It should not be the only way to identify though.
An ssh-style key + password is fine. A username + password + TOTP should also be fine. But 99.9% of passwords should be in a password manager anyway.
Rescue codes should always be generated and written down when activating a passkey or similar, but this requires certain discipline, some feeling of importance. And many web sites that require registration don't seem important for users, especially one-time users. What makes sense for your Google account, or your bank account, feels like too much ceremony for a low-stakes login like a random online store; losing a login to it does not feel like a big loss to many people.
I disagree. It is very annoying when some service fails to show an option on the grounds that I can't use it. If the option is just missing, I have no way to tell whether the company doesn't provide the option, whether the company made some sort of mistake (they can't provide an email option because they lost my email), whether I made a mistake, or whether the company just has a bad UI that tries to hide the option. It makes it difficult to resolve problems.
They should show it greyed out with a note "no key of this type registered".
I use bitwarden, Google and a yubikey for passkeys. Which of these am I locked into?
People wrongly think passkeys are like Bitcoin wallets, where losing them means there's absolutely nothing you can do, your account is simply lost forever.
Losing a passkey is exactly like losing your password, which is to say, that for 99% of services, you can reset your password/passkey really easily. There's a prominent "Reset Password" button right on the login form. It sends you an email or an SMS, you click it, and it lets you reset right then and there. You can reset your passkey in exactly the same way.
It is not that easy to reset if you lose your password to your Apple, Google, Facebook, etc. They all have a bunch of factors that they use to authenticate you if you reset your password, and they don't even document which ones they use.
So, if you care about those accounts, you've got to make sure you have backup access. They all let you generate and print "backup codes" (emergency passwords) and store them in a fireproof safe or a literal bank vault. Do that!
As everybody knows, you can't store all of your passwords in a password manager. You need something outside of the password manager to login to the manager itself. That's why 1Password/LastPass is called that; you still need one last password that you keep and manage yourself.
That's true of passkeys, too. You can login to Google with passkey, but if Google is your password manager that stores your passkey, you need something else outside of Google's password manager to login to Google. Whether it's a password, a backup code, a YubiKey, whatever, you need one more thing to login to Google, ideally more than one, so you can back it up and keep it safe.
Security engineers are prioritizing preventing key copying over lockout issues, unilaterally, on literally billions of people. It improves their metrics internally, at the cost of an externality on the entire world. This kind of stuff invites odious regulation as more and more stories of lockout with no recourse surface.
And unlike passwords, there is no good provider migration story. There is a roach motel issue. Yes it is being 'worked on', but passkeys and such have been out for many years, the willful denial whenever you ask people running these standards about these issues incredibly irritating. The fact they tend to avoid questions about this like politicians decreases trust in the motives of such standards.
I'm curious what the "good provider migration story" you're referring to here for passwords is?
Password managers by-and-large haven't agreed on a standardised interchange format for import/export - a few of them have some compatibility helpers for importing from specific popular competitors but they're all in different formats, no consistent formats.
The above goes for passkeys as it does passwords - import/export will include your passkeys - so I don't see much difference in the provider migration story.
On the other hand, the FIDO Credential Exchange Format does solve the above problem (if/when providers choose to adopt it), so passkeys are at least further along the path of creating a "good provider migration story" than passwords ever were.
Passwords right now are outright better.
And by the way, door keys could be copied.
They work on all my (not just Apple) devices seamlessly.
I don’t need to copy them.
Non walled ecosystems are nice.
Yes, absolutely. I have a second Google account I created and lost the password to. I can't reset it because it wants to know the exact month I opened it. I don't even know if it was 2012 or 2016, I'll never guess the month.
The answer to that is stuff like this:
https://blog.google/technology/safety-security/recovery-cont...
https://support.apple.com/en-us/102641
People keep falsely imagining that Google is setting people up with passkey-only accounts, with no way to backup their login credentials. Gosh, wouldn't that be terrible?
That would be like 1Password letting you create a passkey-only account with no password, storing the only passkey in 1Password. The whole idea makes no sense. 1Password doesn't do that, and neither does Apple, Google, Microsoft, etc. (We can all imagine them doing something that stupid, but, it turns out, they don't.)
Pre-passkeys, the most common lost-credential scenario was creating a fresh Gmail address on a new device (an Android phone) with a password and forgetting both your Google password and your password for your cellular-phone carrier (AT&T, T-Mobile, etc). Your Google password would be stored locally on your phone and in Google's cloud, but when you lose your phone and forget your passwords, no backups remain.
At that point, you're pretty much screwed. Google can't email you a reset-password link, because Gmail is your email. Google can't you send a 2FA SMS until you get a new phone with the same number, but you can't convince AT&T to do that, because they want to send a reset-password link to your email, which you don't have, or SMS to your phone, which you don't have.
(The cellular carriers don't even allow you to show government ID at a physical store. They don't allow you to take over a phone number that way, because people could then threaten/bribe a T-Mobile store representative to falsely claim that you presented valid government ID, taking over other people's accounts. If you walk into a store, they'll just put you on the phone with customer service, where they'll insist that you provide your AT&T password, or reset your password via email or SMS. If you've lost your email and your phone and all your passwords, you're completely out of luck.)
If Google allowed you to create a passkey-only account, with no SMS 2FA and no way to backup your passkey, that would be even worse.
But, luckily for all of us, they don't even allow that, and they're certainly not pushing it unilaterally on billions of people.
You can with KeePassXC, so it is a choice of the credential manager implementation. The standards people want to ban such credential managers though.
If I log in to a site from my machine, and set up a passkey, but then log into that site from another machine, it'll just see no passkey present and ask for my password, yes?
A passkey is a local password on a device that could be shared through all the password manager gymnastics, but its not required as I understand it.
Passkey generated on a device can only change login flow for this one specific device. If you don’t synchronize passkey to other devices or if you do not generate passkey on other device, then login flow is different for other device. You need to enter password.
Imo it would not make any sense if it was different.
Not every provider does this correctly. Just yesterday I saw someone complaining on mastodon about their passkeys being locked and requiring a phone call to get reset.
Passkeys are exactly as resettable as passwords, which depends on your provider actually implementing things correctly.
Most sites/systems that are designed for security won't have such an admin UI - passwords should generally not be handled in a way where anybody other than the user is ever able to know what they are.
Sure I'm super secure using a passkey.... except that there's always a "try another way" option on the login screen. Which defeats the purpose.
Passkeys, stored in Bitwarden, give a lot of the same convenience, but without the vendor lock-in. We shouldn't be scaring people away from passkeys, when commonly used alternatives are much worse.
You can't back up your passkeys and wind up with something you put in a safe on a USB key or something and vendors have been aggressively trying to make that harder.
On Apple devices I get neat experience out of the box, on Linux (+Firefox) I forced to use Bitwarden because Mozilla is being Mozilla.
Never had any issues ever with passkeys.
As a tech-savvy user fully aware of the underlying machinations involved with passkeys, I greatly prefer their simple, fast login experience over: username submit password submit TOTP submit, and especially over the much-worse "we've emailed you a code" login slog.
Passwords on a piece of paper for better or worse do not have that problem.
This is without 2fa enabled on my Google account.
I'm also pretty sure I don't have any accounts that can ONLY be accessed via passkey.
Maybe because your kid was playing with your phone and kept entering the wrong passcode and now you’re locked out for several hours?
Or because Apple detests anyone else touching your phone and you’re traveling internationally and your screen cracked and you took it to a local repair shop which in the process of replacing the screen triggered something Apple didn’t like and you’re locked out for a decade.
And even if they're not, if they have a computer or tablet, the passkey will still be available there, allowing access.
Stop the insanity.
48 more comments available on Hacker News