Comment by the__alchemist
5 days ago
Same. I don't understand it, and there is enough conflicting information (See this article pair as an example) that I suspect it's not something where I just need to do more reading. I suspect there's something fundamentally confusing, and subjectively-interpretable about this.
My suspicion: There is a significant chance I will lose access to one or more account by doing this, so I'm not going to until the air clears. I don't trust the motivations of the services pushing it.
This may or may not help depending on how technical you are, but at the core a passkey works through public key cryptography, like SSH keys work. Setting up a passkey with a site involves sending a public key to the site, which they store as being owned by your account. Then, to sign in, they use your public key to generate a challenge, you use your private key to solve the challenge, and you respond proving you have the corresponding private key.
This means you never send your private key to the site, so if their database is compromised they only get a public key, which can’t do anything (it is public, after all)
No amount of phishing can get you or your client to hand over your private key, because there is no use case where that is required. There is no possibility of MITM, since your private key is never sent anywhere in any situation.
As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.
This is a fantastic explanation and analogy. Thank you!
I will poke at this a bit:
> As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.
Do you think this is one of those scenarios that sounds reasonable at first, but can get torn apart by unknowns, edge cases etc? To use an analogy from a recent HN thread that is stretched a bit, is this like saying "If you use a crypto hardware wallet, you're safe", then reading about compromised hardware wallets due to something outside the assumption set.
The threat models here are often very similar to existing Password Manager threat models. If an attacker gets access to your Password Manager they get access to every password you have stored there and can do what they like with that information. The same applies to your Passkey Manager, which in many cases (including for your own peace of mind) is/should be the same app/vault as your Password Manager for other types of passwords.
A lot of the same Password Manager requirements and best practices apply to Passkey Management such as using strong master passwords or biometric unlocks or device PINs. Using Password Managers that support device bound hardware security enclaves, etc.
But even more so than average Password Management, because Passkeys are public key infrastructure the benefits you get out of the box exceed those of ordinary passwords. One of the factors in most Passkey implementations here is that sites (defined by hostname) all get different public keys. (Users are suggested to use different passwords for every site, but are not required to. Passkeys do that technically and are generally enforced in that effort by browsers and Operating Systems.) Leaking those public keys is no longer an issue (they truly are public keys), and leaked public keys aren't generally useful to other sites and apps. (Passwords that leak and even sometimes salted and hashed passwords that leak are liabilities and can be useful for rainbow table attacks or social engineering attacks or password reuse attacks.)
There are certainly edge cases to Passkey Management but in general the threat models follow Password Management threats: does someone have physical access to your device? Do they have access to your biometrics or device PINs?
But also the blast radius is reduced compared to usual Password Management threats: a single leaked private key generally only impacts a single website/app. Being able to sign a Passkey challenge once doesn't mean unlimited access (a password can be used forever after finding it), because challenges have timestamps and random entropy and generally don't support replay at all.
5 replies →
The risks from using passkeys are a subset of the risks from using passwords. There aren’t zero risks, just fewer than for passwords.
If you own only one device—a mobile phone, like the majority of people in the world—and you lose it, how do you get back into your passkey-protected email account?
This is site-specific, but typically by using the same mechanisms used to reset forgotten passwords.
Also, sites can and often do support multiple passkeys, which opens up the possibility of allowing for reliable account recovery using one or more backup devices (one or more YubiKeys, for instance) that is still siginificantly more secure than reset flows using SMS or email.
1 reply →
Backup codes, sms backup, trusted user backup. Most of these are quite insecure but better than loosing access to your digital life.
How would you get back into your email account if you lost your password or password manager? It is the exact same situation.
Most Passkey implementations by default are syncable/copyable/backupable. The iOS default is iCloud Password Manager and keys get backed up to iCloud and restored on device restore when replacing a phone (just like the rest of the users passwords they choose to store). Android has similar defaults with the Chrome Password Manager.
That is my understanding as well but I like to point out: The private ssh key lives on the hardware it was created on. It never leaves the system. Even root cannot "copy paste" that sucker around and chuck it into a password manager app or even "better" on a cloud service so you can use it on any device you log into.
I liked the idea that passkeys work the same way but now for logging into services like amazon or google etc.
Imagine my face when I learned that that so many interpretations of passkeys exist that actually create that private part in a passwordmanager or chuck it into iCloud or equivalents.
I wondered if the inventor of the private/public keyexchange still lives or if he would spin in his grave hearing what happened...
I would have been on board if the passkeys only existed on your hardware period. I would have accepted that I would need to set up access from devices of my choosing and therefore cannot log into these services from any old "cyber cafe" on a whim.
But I would, as an emergency BCM measure, expect a sort of breakglass phrase that I could obtain and keep safe like at a bank deposit box or similar in case all hardware with keys to said service would die at the same time.
I understand though, that for most all this would look like way to inconvenient and using the cloud instead is so much more convenient which is why they decided to hollow out the concept of the passkey.
What’s PQ story with passkeys? Considering all the hype that everything needs to be pq safe by 2029 (or whatever), wouldn’t it make sense to delay adoption? Otherwise a db leak would compromise every single account in a pq world.
Authentication is safer than encryption, because harvest-now-decrypt-later is not available. Currently PQ is not standardized for passkeys, and at least Firefox fails if the authenticator advertises unknown algorithms.
Most Passkeys use PQ PKI algorithms. From statistics I've seen most are Elliptic Curve on currently recommended PQ curves.
For better and worse, Webauthn is one of the "choose your own adventure" PKI systems where the keys themselves suggest which PKI algorithm/details they use. This is partly because Webauthn has been around a long time and has had to backwards compatibly support a wide variety of physical security keys over the ages.
Most good open source libraries for implementing passkeys will do a good job of limiting passkeys to known good algorithm choices, including any PQ requirements/suggestions. The Passkey standard itself also sets a "higher water" baseline above Webauthn's supported algorithm list.
2 replies →
Passkeys aren’t permanent, you can change or revoke them. If the algorithm used suddenly becomes vulnerable, you would need to rotate all your passkeys.
6 replies →
It doesn't help that the primary benefit we get from passkeys, in exchange for a lot of pain and fragility, is that phishing is harder to pull off. That's a big deal for a lot of people, but frankly, I'm not one of them. I already know not to click on links in emails.
I've never fallen for a phishing attack and any attack targeted and sophisticated enough to catch me is probably going to be sophisticated enough to steal/hijack a passkey anyway. In the extremely improbable event that I did get phished and somebody got into my account somewhere, they'd only have access to that one account because unlike most people I don't re-use passwords and recovery would no more complicated than contacting customer service and resetting my password with them.
Considering the horror stories of people who been screwed by using passkeys, I'm sticking with "not worth the trouble"
The easiest way to think of it is they are like ssh key auth where the keys are stored in your password manager.
I have no doubt users will get confused about which password manager they have their passkey stored in, but these are the same users who don't know what a password manager is so they share a password across everything and get hacked regularly.
With the exception of general-purpose authentication services like Microsoft Entra ID where organizations can set pretty much arbitrary authentication requirements, I've yet to encounter a site where merely setting up a passkey disables other forms of authentication.
The benefit of adding additional authentication methods without disabling others is limited, of course, but it can still be useful where, e.g., you're comfortable logging in using a password manager on your own devices but want to use an iPhone or YubiKey to log in from public computers.