Are passkeys replacing passwords, 2FA, or both?
What if I created a passkey on some device, lost that device, and my passkeys aren't cloud-backed-up? Would I be able to recover my account, or it's doomed? Or does it depend on how a given website implemented it?
You kind of have to go out of your way to not have your keys backed up. By default, the easiest route is using your android or iphone and both of them back the keys up using icloud Keychain or google password manager. 1Password, bitwarden, all support syncing. Chrome will allow saving it to icloud or your google account. Keepass can be manually synced. Windows is adding sync in the next update for windows hello. List goes on.
The other thing is that multiple keys can be created. Easiest way to see this in action is google's account security settings. Log in (if you have an account), hit create passkey, see your options and play around with them. You'll also see you can add a hardware security key too, which isn't nothing new but if you have one that's another key that doesn't rely on a mobile device!
If all else fails, the usual account recovery process applies. Much like it would if you forgot your password.
And if my google account gets banned, I lose access to a trillion things instead of just one.
I was hoping passkeys would work on 1password,but chrome/brave don't support that yet.
It seems like a passkey is just a password though
They are advertised as a replacement for passwords, but the truth is that they are orthogonal to both passwords and 2FA. They are a completely different kind of authentication.
Both passwords and passkeys work by proving that you know a secret. The difference is that with a password, the way you prove that you know the secret is by revealing it, which leaves you open to phishing. The other problem with passwords is that the secret is generally one that you are expected to type and remember, which limits how long and random it can be.
With passkeys, the secret is a public key (EDIT: in the sense of public-key encryption. The secret is actually the secret part of a public-private keypair), that is, a long string of random bits that a normal human could not remember even if they wanted to, and the way you prove that you know it is using that key to produce a digital signature for a random challenge. You never reveal your key during normal operation, and that makes it more resistant against phishing.
> What if I created a passkey on some device, lost that device, and my passkeys aren't cloud-backed-up? Would I be able to recover my account, or it's doomed? Or does it depend on how a given website implemented it?
It depends on how a web site implements it, but keep in mind that everything that makes it easier to recover from a lost key also makes your account more vulnerable to attack. So having backups of your passkey keys is a really good idea. But those backups don't have to be in the cloud. You could keep local copies on your own devices, or even print the key on a sheet of paper and keep that in a safe.
Obviously this isn't bad advice, but it is the reason I won't be diving into passkeys any time soon. Firefox Sync (the original version) had this philosophy: it's perfectly secure but if you lose your key, you've lost your bookmarks, history, and anything else that gets synced. For non-power users this is a catastrophic failure mode. For power users this still happens and it sucks. I was at Mozilla during this time and the failure modes of Sync were impressively common, even among employees.
Nobody expects to lose their backup. If you were a victim of hurricane Helene, it's entirely likely your safe is gone and all of your devices are destroyed. If that also means you've permanently lost access to your files or email or whatever, that's really really bad. And completely within the realm of possibility!
Obviously you can't fix this with cryptography alone. But it shows that passkeys can't be implemented as a full solution.
WebAuthn credentials are bound to the issuing domain, so the user agent will not supply a passkey to a domain other than the one it should go to.
Based on my (limited) understanding from reading the page: 1. Server generates challenge, sends a challenge 2. User device signs the challenge by encrypting with its private key, returns the signature. 3. Server verifies the signature by decrypting with the public key.
As you mentioned, the private key (the only thing that can generate a valid signature) isn't leaked.
They're as secure as having your password + 2FA in a password manager.
Yeah, I meant "public key" in the sense of "public-key cryptography". I've edited the comment to make this clearer. Thanks for pointing that out.
> Based on my (limited) understanding from reading the page: 1. Server generates challenge, sends a challenge 2. User device signs the challenge by encrypting with its private key, returns the signature. 3. Server verifies the signature by decrypting with the public key.
That is almost exactly right, but since we're being precise here, I would just pick on this one very minor nit:
> User device signs the challenge by encrypting with its private key
> Server verifies the signature by decrypting with the public key
"Signing/verification" and "encrypting/decrypting" are two completely different things. In RSA these are conflated, but it's important not to confuse them. With elliptic curves, these have nothing to do with each other. It's just a peculiarity of RSA that makes it encrypt/decrypt to do digital signatures.
Well, OK, but what is the alternative?
(Actually, you don't need to manually keep backups. You can have automatic backups, but those come with their own set of risks.)
[0] https://github.com/keepassxreboot/keepassxc/issues/9339
[1] https://keepassxc.org/blog/2023-06-20-cve-202335866/
edit: This actually might be a better thread to hear some of the debate between an Okta dev and the KeepassXC team:
The minimum bar is replacing passwords with something more secure for the user.
If the site wants more specific factors or characteristics of authentication (such as a non-cloneable possession factor) then only some authenticators provide that today themselves. For someone using a synced software provider, they will need to do an additional step to meet this sort of requirement.
Factors aren't nearly as solid as they are made out to be - my SMS OTP is synched to all my devices, my TOTP keys come from a software implementation right alongside my password - which isn't a true knowledge factor because it was auto-generated for me. Password managers and other software have long put us on the path of sites leveraging externalized authentication processes and policies, similar to how they might do this explicitly by accepting federation.
> What if I created a passkey on some device, lost that device, and my passkeys aren't cloud-backed-up? Would I be able to recover my account, or it's doomed? Or does it depend on how a given website implemented it?
The syncing is meant to make it harder to lose the passkey. Sites still ultimately have to have a recovery process when someone does lose access.
It can also be used as an second factor for traditional username/password auth (with or without user verification).
Losing a passkey is no different to losing any other credential: you need another method to authenticate or recover your account.
It depends on the type of attack being mounted, but a typical phishing attack is mounted as a MITM attack. With passkeys, a MITM cannot get the client to even ask the user to approve the transaction because the attacker cannot authenticate as the relying party.
You can attack passkeys by, say, compromising the user's machine, but that's not phishing.
EDIT: Private key is not transmitted off of your device when authenticating, but it can be transmitted off of your device by your password manager.
"The difference between passkeys and passwords is that passkeys are cryptographic key pairs. The key pair is specific to a website. One half is shared with the website, and the other half is private and stored on your device or in your password manager." [0]
"Passkeys are securely backed up and synced between your Android devices" [0]
"Passkeys are stored in your Google Account..." [0]
"Your iCloud Keychain stores and syncs them [passkeys] between iOS, iPadOS, and macOS devices." [0]
Do they? Is that legally mandated somewhere, or can they just say "You're stuffed, make a new account if you want"?
It’s just your login credential.
If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.
It’s just your login credential.
If you lose either a password or a passkey, you do the same thing: set a new one via email recovery.
Banks aren't perfect but mine already has all my money and the deed to my house. I trust the safety of my bank more than I trust Google not to lock me out or all my hardware to be destroyed.
Thank you. I should have been more specific. Non-transerral during auth is important because it virtually eliminates fishing, and that also explains why the Powers That Be are touchy about exporting. Exfiltration enables scenarios where a nefarious party tricks a user into transferring their cryptographic keys.
[1]: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...