Hacker News

I like the concept of them, and I want them to work well purely so people stop using bad passwords. But nearly everywhere does it differently and weirdly and likely wrongly.

When I log into my Amazon account with a passkey, it then asks me for a 2FA code. The 2FA code is stored on the same device as a passkey, that step literally does nothing. After I do the 2FA code, it then prompts me to create a passkey. No! I have one. I signed in with one.

Some devices give me the option to use a QR code. I like that option usually, I can easily use my phone to authenticate. But sometimes i can’t get the QR code to appear. Support varies by OS, browser, and set of installed extensions. And there’s no easy way to control which of those three handles the passkey when something decides wrongly.

I had to troubleshoot something on someone else’s computer, and saw that they logged in to windows with a passkey and QR code. I’ve looked, and I can’t seem to set that up on my windows computer. There isn’t an option to and I have no idea why.

Yup. I hate them. I get the problem they're trying to solve, it just seems like I have more work to do... and I honestly don't even follow what is going on sometimes.

I recently moved to a new computer and it's just an AUTHHELLSCAPE.

Passkeys on iOS and macOS actually work quite well in that regard. They get stored in your provider of choice across the web, web views, apps etc., at least in my experience.

Mine is Bitwarden, and that's available on pretty much all platforms, natively where available (except on macOS currently), as a browser extension otherwise.

For the rare instance in which I need to authenticate using a passkey on a computer where I'm not logged into Bitwarden, there's the cross-device CaBLE flow where I can scan a QR code with my phone and use Bitwarden to authenticate. This works across OSes and browsers.

I truly don't see the advantage of passkeys over a password manager like bitwarden, with random passwords.

There’s another foot gun I wrote about recently:

https://cedwards.xyz/passkeys-are-not-2fa/

I just use iOS' wallet for all of it, the only exception being if its something I 100% need to open outside of my iphone / macs. Then I go for BitWarden, turns out I dont need any apps to open outside of that sandbox, I am okay only opening these up on Mac. I can always type my password on Linux. That's what bitwarden is for anyway.

The system always asks where you want to store it, and all passkey managers vend to the system prompt with labels so you can see where it is.

This is not an issue on iOS, I can’t tell how what you’re describing could happen.

>If I had any discipline around this it would make sense but if I accidentally double tap on the screen I've got a passkey and it's stuck on my phone.

The problem is not with passkey rather system such as iOS keeps a tight lid on how files are uploaded and retrieved from the device. There is a real disconnect between desktop and mobile file system now days.

Embedded webviews are the stupidest thing ever. Yesterday I got halfway through a checkout process, had to go back to another app to check something, and then the webview simply disappeared so I didn't bother finishing the checkout. This was on Android

Usually I open it in Chrome but for some reason I didn't realize it was a webview this time

You can just use bitwarden everywhere if you are ok with it in the cloud.

For this reason I am avoiding it like a plague. It is an additional way to fingerprint your activity and the scenarios where you migrate your passkeys from a device to another seems not really well "oiled"

> What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.

This feels more like CYA/shifting the blame for me. If a service is designed so that I will lose all my data if I lose the passkey, then a "yo, don't lose that passkey, like, ever!" warning is the minimum, but doesn't solve the problem.

I found the initial suggestion "don't ever use passkeys for encryption of persistent data" more reasonable.

(Or what the sibling comment describes: Design the encryption in such a way there is an alternate key that could be used for decrypting)

I think the idea behind PRF was something like "use this as one of several keys", never as "use this the only key". I don't think this was explicitly called out in the specs, though.

> this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion

That sounds like a reasonable idea, but still doesn't help with the case of a completely deleted/destroyed authenticator, e.g. a lost Apple/Google account or Yubikey.

The only viable solution to me for mass adoption is restricting (by recommendation, since there's no way to programmatically enforce it) PRF to scenarios where it's only one out of several ways to get access back. Some password managers do this, e.g. they encrypt their master secret under a PRF-derived key, but this is not the only way/place to get to the master secret, and they also encourage printed key backups etc.

This past weekend I watched as my mom discovered the password manager in Chrome, and started deleting every entry she couldn't immediately recognize. "Why is this here? I don't need this"

Despite me pleading that they got there for a reason, and takes zero storage, she was confident she didn't need these passwords. So I can totally see her deleting passkeys; my mom is basically Erica, there need to be very explicit implications stated for every action presented and not assume innate understanding

I consider myself pretty sophisticated with passkeys (I wrote a toy implementation of WebAuthN once to understand them better), and yet I still get tripped up by this sometimes: Not via intentional deletion, but accidental overwriting.

As far as I understand, there are several ways to enforce per-account passkey uniqueness via WebAuthN, but every once in a while, some site will somehow not realize that I have a passkey for them available already, they will offer to create a new one for me, and my password manager (Bitwarden) will do this by overwriting the old/existing passkey.

Now consider a synchronization hiccup (updating my password manager storage and the relying party's backend is not atomic), and I could totally see my passkey get lost.

It's more likely for them to accidentally be deleted (or otherwise lost access): in my experience approximately zero users actually understand where their passkeys are stored, and they can be all over the place: the number one question I get is 'why can't I log in?' because they've accepted a passkey setup dialog on one machine without really reading it and now can't log in on another. Sometimes it's on the same machine but in different contexts. No passkeys should be considered something that the average user is going to reliably hold onto (in large part because the industry has been so keen to foist them on users but not very keen at all to educate them on how they work. This also makes them a lot less useful from a security point of view because it means you can't get rid of the recovery process, which tends to be the weaker link).

the problem so far is UI and incompatibility across devices, OSes etc. I am a big fan of Passkeys and the idea of using PRF for E2E encryption, but I wouldn't implement that as now, there is almost zero control over where those passkeys are, how I can recover them, how I manage them. Whenever I have to switch computer (mandatory policy at work), or phone (mandatory obsolence) or if I want to work across OSes (Mac for work, Windows for fun), everything falls apart, incomprehensible interfaces, inexistent transparency and control. And I'm a pro user that has actually studied how the standard works.

I'm afraid that it'll take some few more decades before we will get rid of passwords, if ever.

> And why are they "cleaning up" their passkeys in the first place?

The same reason they're cleaning up their Windows or system32 folder.

Unfortunately some vendors are now REQUIRING passkeys; specific example:

https://www.healthequity.com

> As of October 2025, passkey login has been fully rolled out and is now required for members with Health Savings Accounts (HSAs) and Reimbursement Accounts (RAs) who use the HealthEquity Mobile app and web experience.

https://help.healthequity.com/en/articles/11690915-passkey-f...

The FAQ is a little misleading by saying WHEN your account has a passkey this and that, but reality is that after October they made them completely mandatory, no bypass, no exceptions. 100% coverage.

Oh, and by the way, passkeys have been broken on PC/Linux when using Firefox for months:

> There Was A Problem: We encountered an error contacting the login service. Please try again in a few minutes.

Neat. You have to use Chrome or Edge.... For months, after making it mandatory...

>They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck

This is the biggest myth/misconception I see repeated about passkeys all the time. It's a credential just like your password. If you forget it, you go through a reset flow where a link is sent to your email and you just setup a new one.

And if it happens to be your Gmail account that you're locked out of, you need to go through the same Google Account Recovery flow regardless of whether you're using a password or a passkey.

I'm also completely against passkeys. A safe password and a good password manager are way better, they don't lock you into any platform.

It's super sad to see all kinds of websites offering you to add a passkey when you log in.

I love passkeys in my selfhosted vaultwarden, but I agree the UX for older people is not quite there.

> They bind you to your device

Isn't it why good practice is to bind at least 2 hardware passkeys and/or have recovery codes?

Sure someone can steal your phone/laptop/yubikeybio but then you can use the NitroKey you have at home in your drawer to recover your account.

KeepassXC has exportable passkeys, so you can avoid the stolen case at least.

Also a password could be the passkey, the passkey protocol is basically a way to send to a server an authenticated public key. The client could deterministically convert passwords to key-pairs and authenticate with those

> They bind you to your device/iCloud/Gaia account

Then don't use Apple's/Google's/whatever Gaia is as your passkey provider?

> Mom can't figure out what they are or how to use them.

Then do something nice for your mom and set her up with Bitwarden, 1Password or KeepassXC, which prevents the platform lock-in.

> It's one further step down the attested hardware software and eyeballs path.

None of the synchronized passkey implementations, which big tech has been pushing lately, support attestation, so this is just FUD.

Yubikeys do, but fortunately they don't seem to have the (non-enterprise) weight to make it mandatory for all passkeys.

The issue I think is that passkey managers don’t make it clear that deleting a passkey can cause permanent data loss

There's a big difference between being kept in the dark and being informed but careless.

I don't know about spring cleaning, but it's pretty easy to delete by accident if you connect to the browser or OS when setting up instead of the password manager.

That said, I've been assuming I could have multiple passkeys per site and that's turning out to not always be something websites behave sanely about.

Most password managers implementing passkeys only allow one passkey per account entry, and I've ended up with multiple passkeys per site, while the site only supports one (and deletes the others upon creating a new one), so I've been in the exact situation of not knowing which entries are safe to delete before.

This is usually due to relying party and possibly password manager bugs, but it does happen.

I thought the point of passkey security is that you don't have to send the private key around, it can stay on your device. Different passkey per device. Lose or destroy a device, delete that passkey and move on.

I think the distinction is that a passkey is meant to be used for authentication (logging in), and is usually not the only way you can authenticate. If you delete your password, passkey, or 2FA method, you can still go through a "forgot password" flow.

Encryption is different. If you encrypt data with a generated password and then delete it, you're toast, and passkeys are no different. I think the author is arguing that users may not even realize that the passkey itself is needed to decrypt, possibly because they're so associated with login.

> you can remember them, but are you also suggesting to not use generated passwords?

You can remember a strong generated password if it's a pass phrase. Better "rememberability" with the same amount of entropy.

Generated passwords can be useful, but they come with challenges like management and security. It's better to adopt approaches like password managers or biometrics to enhance usability while maintaining security.

Sounds like the website did a shitty job at implementing passkeys. I’ve read through the guides and done it myself and yes there are a lot of gotchas and they’re all avoidable.

You're thinking about hardware authenticators, not Passkeys. Passkeys are definitionally synchronized and backed up in the cloud (otherwise you just have a sparkling WebAuthN authenticator).

Proprietary clouds and sync backends create their own set of problems, but they do solve the availability issue of always having to register at least two different security keys with each service.

> to be honest, I wouldn't mind if google/Apple can take all my private data and passkeys hold them

That's exactly what you can do today!

> I show my ID they should allow me to setup my new phone.

You have to show them your phone number, which for better or worse is our age's "showing ID", but then you can indeed get back in.

The author's concern of "misgendering" an imaginary person (with ab unambiguously female name) is quite odd.

I don't think I would have even realized why I felt tension reading if you hadn't mentioned this. They/their wasn't confusing at all but, giving the hypothetical user a name was the weird part. I realize now I was expecting some other user to enter the scenario the whole time. Alice and Bob style. When I got to the end, I felt like I missed something. If there's just one, "the user"/"they"/"their" is fine.

> I actually despair about when my family members are forced into passkeys and then lose access to their accounts because they get a new device.

Both iOS and Android sync passkeys to their respective cloud accounts by default. (Of course, losing access to that account, sharing one across family members and causing confusion etc. are still concerns.)

The real problem is lock-in, as this effectively often prevents entire families from switching from iOS to Android or vice versa. I'd encourage anyone managing their family's tech setup to pick a platform-agnostic passkey implementation such as 1Password or Bitwarden for that reason.

I love the idea of hardware keys, and would absolutely use them for the essential stuff (email, domain registrar, bank) but they're just too expensive, while plain old TOTP 2FA is free and provides 99% of the benefits for my use case. TOTP also has a much better workflow in my experience, but this isn't that big of a problem for the things I'd consider essential, but it would be annoying if I were to use a hardware key for everything.

I can buy 6-8 physical keys for the front door of my house for the cost of one Yubikey. Even though there are options at half price, that then gets eaten into by the need to have two or three of them, since a backup is not optional for this sort of use case. I can't imagine convincing one's parents to buy 'a key for your email account' will be easy when the old way mostly 'worked fine' and was free, meanwhile the new one will cost them a non-trivial amount of money. It's an easy flow if you're their sysadmin, but I wouldn't want to throw my parents into the deep end of hardware keys and have to explain to them that they don't need the expensive one, but still have them be discouraged by the mere existence of 100+ dollar options for what should be damn-near throwaway hardware.

Passkeys somehow manages to have a worse workflow than both though.

If no one can implement a specification without causing problems here and there, perhaps we should consider the specification itself problematic.

See also: Bluetooth.

On a similar note mooltipass can export an encrypted backup of passkeys. That said platform should support multiple passkeys so if you lose access to one you arent screwed over.

It does if you use microg or authnkey or keepassdx.

It's Play Services that does not support this combination, likely to shepherd you towards Google acoount usage. Alternate Android apps work fine.

Why wouldn’t you?

> Don’t believe me? Try logging into a bank or using rideshare/parking/ev charging with degoogled android.

What does root detection and other device attestation have to do with passkeys? Passkeys (at least Google's and Apple's) don't support device attestation.

Passkeys are an open standard? You might as well argue against SSH keys.