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.

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

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.

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

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

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

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.