Don't use passkeys for encrypting user data

Passkeys have way too many footguns for me. If I use my phone to sign in I'm going to accidentally create a passkey there on iOS embedded webview. When I use Google Chrome, the website won't give me any information for me to find where I stored the passkey. Was it in iOS keyring? Chrome? My Bitwarden? 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.

I'm sure it's of use to many people but it's been no end of pain for me and it has really signaled to me what it's like to grow into an old man unable to use computers when I was once a young man who would find this easy.

Security is important, security is important, security is important — I keep emphasizing this point. But for me, that statement only really applies to people who genuinely understand security. I personally bought two YubiKeys, understand the associated risks, and store my credentials on those YubiKeys. However, many people today do not realize the risks involved. They casually store these things in places like a keyring and then never manage them properly. That does not necessarily mean they are secure. On the contrary, it can become another kind of danger, because once you start using passkeys, the level of access and authority tied to them is significant. If they are lost or leaked, the consequences can be disastrous. I am glad to see that the industry is paying more attention to security, but at the same time, I believe these more specialized aspects should be aimed at people who actually have the relevant expertise. Passkeys do have a learning curve. For ordinary users, they often just click through a few prompts and end up binding themselves to a system without really understanding what happened. On top of that, with modern systems relying on encryption and TPM, once a computer runs into serious problems, many people simply have no way to recover their data. For the average user, 2FA is already sufficient.

The core issue here is a category error that the industry keeps making: treating authentication credentials and encryption keys as interchangeable. They have fundamentally different lifecycle requirements.

Authentication is recoverable by design - you can always reset, re-verify identity, issue new credentials. Encryption keys are the opposite: lose the key, lose the data. Full stop. No amount of UX polish changes this mathematical reality.

The PRF extension makes this worse because it blurs the line even further. Users interact with passkeys as "login things" - the mental model is authentication. But when PRF derives an encryption key from that same passkey, you've silently upgraded a replaceable credential into an irreplaceable secret. The user's mental model doesn't update.

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 story of a user deleting their passkey doesn't seem plausible to me. They don't remember why they have a specific passkey for a messaging app? Surely recognizing the app that stores so many memories is enough not to delete the passkey. And why are they "cleaning up" their passkeys in the first place? Yes I put "cleaning up" in quotes, this metaphor, suggesting that a long list of unused passkeys is dirty in some way is inappropriate.

If an app has a billion users, how many do you expect will delete their passkey for no reason? Is this more important then end-to-end encryption for everyone?

If deleting one's passkey for no reason was a thing, I'd expect a real story about a real user, rather then a made-up scenario.

The essay has a condescending attitude towards the normie computer user who can't possibly be expected to know, but it's precisely the normie computer user who would never get the stupid idea of "cleaning up" their passkeys in the first place -- that's something only a nerd with a neurotic attitude to their computer would do.

> Don't use passkeys

Better title.

Mom can't figure out what they are or how to use them. They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck (yeah yeah multiple devices and paths to auth and backup codes, none of that matters). It's one further step down the attested hardware software and eyeballs path. Passwords forever, shortcomings be damned.

Nothing in this post is specific to passkeys; it reads like advice to not encrypt data. There’s no way to prevent some users from losing their encryption key anyway. Whatever warnings you include, even when software doesn't connect to the internet and just encrypts local files, someone will write to support that they forgot their password and ask you to "reset" it.

Good advice at the end, though.

How many people are doing a spring cleaning of unused passkeys in their password managers? We're talking like a kilobyte of data, nobody needs to delete these things in any kind of normal circumstance.

Sure, it would be great if users would store 5 copies of their encryption keys, with one in a lockbox on the bottom of the ocean. But that's just not going to happen at any kind of scale, so an automatic way of putting encryption keys in a replicated password manager makes sense. And compared to how people normally handle end-to-end encryption keys, it's going to result in a lot less loss data in practice.

It is conundrum that passkeys were designed to help the majority as they are frictionless (like passwordmanagers etc) but fail in reality.

Even those that have 2 devices they don't have them all the time.

Another overlooked issue is that some banks etc don't allow for 2 devices as login or 2FA. Even if it allowed one needs to keep the spare device always updated. Either Govt needs to build a common API that one can use directly through google pay or apple pay - so that only one app is needed to be kept up to date.

to be honest, I wouldn't mind if google/Apple can take all my private data and passkeys hold them - but at least then if I lose the phone - and I show my ID they should allow me to setup my new phone. But that is also not possible. (I am discounting the awful AI bans)

> "Even if there were explanatory text, Erika, like most users, doesn’t typically read through every dialog box, and they certainly can’t be expected to remember this technical detail a year from now."

Passkeys are a step in the right direction, ironically for the exact reason the author advises caution. We've been telling people to "store your backup key somewhere safe" for the best part of a decade now, and your average Erika hasn't got on well with that at all. Locking themselves out and losing data left, right and centre.

If you've worked at any kind of scale you'll know well that a certain percentage of users will lose their data with E2EE, full stop. It's just different from everything else they've ever used. These are the same people who'd be lost without the "forgot password" link, and there's no shame in that. That's just the reality of it. And passkeys can help people like this to not lose their keys.

If the product is truly E2EE, the best options right now are the passkey implementations baked into Chrome or Apple. Windows, as ever, needs a bit of work, but the password managers seem to be picking up the slack well enough. We also need to educate people that with true E2EE there is no "forgot password" email. Passkeys and the tooling around them still have a ways to go, but we're getting there.

If the user deletes passwords they're shown the same exact message. The only saving grace for passwords is that you can remember them, but are you also suggesting to not use generated passwords?

Somewhat related, i recently ran into the issue, after i created an account on Confer.to [1] on my Desktop, i couldn't login on my iPad / iOS with Proton Pass and/or Bitwarden.

The error message was: "Error: "Authenticator did not return a PRF result — this passkey probably isn’t PRF-capable."

So i now have an account, but can only use it on my Desktop. (can't change to a password login either, it's Passkeys only...)

[1] end-to-end encrypted AI, developed by Moxie Marlinspike, the founder of Signal: https://confer.to/

Honestly we peaked at Hardware U2F keys. Passkeys were a step backwards.

They were secure, scalable, and they were simple to explain to my parents ("This is a physical key for your email account; like your front door key").

Passkeys to me come across as a part solution to a valid problem. Education is part of the solution. Treating the user as too dumb to understand why they need strong passwords or passkeys is important.

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.

I use passkeys from keepasxc because the native workflow for passkeys is opaque and easy to misunderstand what you are actually doing. And it's predicated on having an account with big us tech companies.

Don't use Passkeys.

(Or at absolute minimum don't force them on unsuspecting users, make them opt-in, not opt-out frequently at random times (Amazon!!!).)

This is why I haven't started using passkeys. Managing them is looks complicated and I don't understand the ramifcations of what I'm doing.

Also a style nit, it's OK to use "he" or "she" pronouns in a contrived narrative. The "they/their" usage really detracted from the clarity of the example.

I recently whipped up a bare-bones PWA wrapping Typage[0] into a quick-and-dirty tool to encrypt files individually using passkeys:

https://news.ycombinator.com/item?id=46895533

This give much more conscious control to the user knowing that they are explicitly encrypting which file with which passkey. Additionally, you can just download the page and serve it via localhost so that you always have control of the relying party for your passkey.

[0] https://words.filippo.io/passkey-encryption/

Probably everything else is debatable, I do agree with one thing though, the cat is indeed out of the bag. It would have been probably a really good use case if the scope was limited to only hardware based security keys for enterprise users only. Rolling it out for OS platforms, software based authenticators just muddies the water. You cannot even provide any guarantees around it being phishing resistant anymore.

The title could've been shorter: don't use passkeys. Period.

The crazy thing is that for a non synced device bound passkey you are tying that user to the device forever.

I was looking into this to start using this. Because it’s quite user friendly to not let the user worry about all the details that involve encryption of data.

I guess informing them is a good way to start. Are there any other tips on how this can be improved?

So... Don't use the PRF extension for its declared purpose? I really wonder how people keep getting Passkeys wrong!

Passkeys aren’t going to make it unfortunately but that’s ok.

They’ll teach us what we need to know to create something that will do what they’re trying to do.

Trezor support FIDO2 tied on the seed phrase, so if you lost it another hardware wallet will works issueless once restored.

I don't use passkeys because I am scared that I will not be able to recover my account with my email address.

Still android doesn't support NFC in combination with resident passkeys.

Another way to say this is that you have to have an account recovery process and you need to think about how your encryption interacts with account recovery.

100% of the arguments against using passkeys for e2ee data apply to using passkeys as credentials.

(Unless they are not credentials, and you can loose them then do a password reset via a phishing prone channel like email and SMS. Supporting this eliminates any possible user benefit of passkeys.)

In addition to the arguments in the article, when used as credentials, they are an obvious trojan horse allowing large websites to completely hijack your operating system.

Don’t believe me? Try logging into a bank or using rideshare/parking/ev charging with degoogled android. This is where passkeys are taking PCs, and it is their only purpose.

So, “Don’t use passkeys” would be a better title.

If the user deletes passwords they're shown the same exact message. The only saving grace for passwords is that you can remember them, but are you also suggesting to not use generated passwords?

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.

I recently whipped up a bare-bones PWA wrapping Typage[0] into a quick-and-dirty tool to encrypt files individually using passkeys:

https://news.ycombinator.com/item?id=46895533

[0] https://words.filippo.io/passkey-encryption/

The title could've been shorter: don't use passkeys. Period.

Honestly we peaked at Hardware U2F keys. Passkeys were a step backwards.

They were secure, scalable, and they were simple to explain to my parents ("This is a physical key for your email account; like your front door key").

It is conundrum that passkeys were designed to help the majority as they are frictionless (like passwordmanagers etc) but fail in reality.

Even those that have 2 devices they don't have them all the time.

Good advice at the end, though.

Somewhat related, i recently ran into the issue, after i created an account on Confer.to [1] on my Desktop, i couldn't login on my iPad / iOS with Proton Pass and/or Bitwarden.

The error message was: "Error: "Authenticator did not return a PRF result — this passkey probably isn’t PRF-capable."

So i now have an account, but can only use it on my Desktop. (can't change to a password login either, it's Passkeys only...)

[1] end-to-end encrypted AI, developed by Moxie Marlinspike, the founder of Signal: https://confer.to/

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.

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.

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.

>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.