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.
peterspath 5 minutes ago [-]
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?
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?
bensyverson 15 minutes ago [-]
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.
dansjots 7 minutes ago [-]
for account-associated encryption, what it should do instead is to generate a dedicated file encryption key for each backup, and encrypt said key with the account's passkeys. Each time the user adds a new passkey, it should save an additional copy of the backup's key encrypted with the new passkey. This way you can have multiple redundant passkeys that can decrypt the backup. This is basically how age's multi-recipient encryption works.
johncolanduoni 2 minutes ago [-]
Most of these systems already do this, especially since very few applications have a flat encryption key hierarchy regardless of passkeys. The counterpoint would be that not everyone will set up multiple passkeys unless you require it on sign-up, but you're going to have that problem with any other method of storing end-to-end encryption keys. Might as well piggy-back on the password manager's replication methods.
dansjots 15 minutes ago [-]
I recently whipped up a bare-bones PWA wrapping Typage[0] into a quick-and-dirty tool to encrypt files individually using passkeys:
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 origin for your passkey.
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.
hedora 14 minutes ago [-]
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.
inkysigma 9 minutes ago [-]
Passkeys are an open standard? You might as well argue against SSH keys.
hedora 5 minutes ago [-]
The standard includes a hardware attestation path.
That’s the backdoor allowing the eventual takeover of your OS.
First people use passkeys, and they become standard.
Then they become required for important accounts for security.
Then the important accounts require the attestation bit.
At that point, you cannot run web browsers on open source operating systems.
This is all boring and predictable. It is exactly what they did with Android, and exactly the same organizations are pushing passkeys.
Note: If they had good intentions, the operating system would manage any attestation, and not allow websites to query for or require attestation support.
27 minutes ago [-]
wmf 14 minutes ago [-]
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.
SoftTalker 24 minutes ago [-]
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.
20 minutes ago [-]
kgwxd 11 minutes ago [-]
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.
Rendered at 04:16:38 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
I guess informing them is a good way to start. Are there any other tips on how this can be improved?
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.
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 origin for your passkey.
[0] https://words.filippo.io/passkey-encryption/
Good advice at the end, though.
(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.
That’s the backdoor allowing the eventual takeover of your OS.
First people use passkeys, and they become standard.
Then they become required for important accounts for security.
Then the important accounts require the attestation bit.
At that point, you cannot run web browsers on open source operating systems.
This is all boring and predictable. It is exactly what they did with Android, and exactly the same organizations are pushing passkeys.
Note: If they had good intentions, the operating system would manage any attestation, and not allow websites to query for or require attestation support.
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.