Comment by cortesoft
5 days ago
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.
Passkeys also open up other use cases like using a mobile device or hardware security token to log into sites from public computers, which, while not risk-free (targeted malware could still hijack your session while you're logged in), is still significantly safer than giving the public computer a password.
This is roughly analogous to the difference between swiped/card not present and chip/NFC credit card payments. While a hacked chip/NFC credit card terminal could display a different amount than actually charged, it can't subsequently make additional charges after the card or device is withdrawn.
2 replies →
I am less interested in the threat models than the accidental denial of service models. I've avoided passkeys because of that. It seems like there are real problems if you use multiple devices not somehow symced.
1 reply →
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.
I think the point is I can make a physical copy of my backup email and password. How do I print a passkey for safekeeping?
In other words, my email can be signed in from anywhere on purpose. It's a feature. The chances of me forgetting my password is zero, because I can back it up 7 way to Sunday.
A passkey seems to miss these basic accessibility issues. For a random website, that's fine, but for the service all of websites use to auth me, access is more important than locking it down to one device.
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.
I don’t follow? What is a “currently recommended PQ curve”? As far as I understand, the entire point is that all ECC is broken by quantum computers, hence the hype to move to something else by 2029. Anyone that can see your public key can compute your private key.
1 reply →
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.
Sure. You’re assuming every site will revoke your passkey when that happens though. It also feels like a great time to trick people into registering an attacker passkey instead.
5 replies →