Most active commenters
  • lisper(7)
  • bastawhiz(5)
  • scherlock(3)

←back to thread

225 points Terretta | 22 comments | | HN request time: 0.002s | source | bottom
Show context
jakub_g ◴[] No.41863841[source]
Something that is not clear to me about passkeys and makes me uneasy to start using them:

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?

replies(6): >>41863858 #>>41864360 #>>41865277 #>>41866433 #>>41866779 #>>41866793 #
1. lisper ◴[] No.41865277[source]
> Are passkeys replacing passwords, 2FA, or both?

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.

replies(4): >>41865612 #>>41865632 #>>41865683 #>>41865684 #
2. scherlock ◴[] No.41865612[source]
I don't see how passkeys do anything to prevent phishing.
replies(4): >>41865645 #>>41865646 #>>41865662 #>>41866844 #
3. bastawhiz ◴[] No.41865632[source]
> 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.

replies(1): >>41865652 #
4. bastawhiz ◴[] No.41865645[source]
How exactly do you get someone to give their passkey private key to a bad actor?
replies(1): >>41866054 #
5. lisper ◴[] No.41865646[source]
Two main ways: first, as I said in my original comment, you don't reveal the key when you use a passkey. So at worst a phisher might be able to get you to sign a challenge that they are facing to get into your account once, but they would not be able to re-use your credentials to get in again or to get into another site. And second, in a proper implementation you would have a separate key for every site you want to authenticate to, so a phisher would not have to merely phish you, they would have to mount an MITM attack on an HTTPS session (or find some other way to impersonate the site they are trying to phish your credentials for). That's not impossible, but it's orders of magnitude harder than impersonating a site through a typosquatting attack.
replies(1): >>41866169 #
6. lisper ◴[] No.41865652[source]
But that's not a problem with passkeys, that's a problem with Firefox Sync.
replies(1): >>41865711 #
7. sitharus ◴[] No.41865662[source]
Phishing relies on visual confusion to get people to enter their passwords on a site that isn't the one they think it is.

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.

8. regedit728 ◴[] No.41865683[source]
Minor correction (I'm assuming it was a typo) -- the secret for the passkey should be the private key. The server stores the user's corresponding public key.

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.

replies(1): >>41865726 #
9. ◴[] No.41865684[source]
10. bastawhiz ◴[] No.41865711{3}[source]
It's a problem for anything where you need to manually keep backups of key material. It's why so many cryptobros lost millions (billions?). If you expect the average person to keep their passkey backup stored well enough to avoid the possibility of physical disaster or losing access to their Google Drive, you've set them up for failure. And when the stakes are losing access to your online life, that's a catastrophic design flaw.
replies(1): >>41865739 #
11. lisper ◴[] No.41865726[source]
> Minor correction (I'm assuming it was a typo) -- the secret for the passkey should be the private key

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.

replies(1): >>41866906 #
12. lisper ◴[] No.41865739{4}[source]
> It's a problem for anything where you need to manually keep backups of key material.

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

replies(1): >>41870028 #
13. scherlock ◴[] No.41866054{3}[source]
"Hi, this is Bob from blah support, we need to confirm your account is a correct. When prompted please confirm to give us access". if someone is dumb enough to hand out a password, they are dumb enough to click approve. Phishing is a social attack, not a technical attack.
replies(2): >>41866566 #>>41869995 #
14. scherlock ◴[] No.41866169{3}[source]
So, it really doesn’t prevent phishing. If you can get someone to give you their password, you can probably get them to click approve. The real benefit is to the service provider, not having to worry about leaking a secret if they get compromised.
replies(2): >>41866925 #>>41866976 #
15. tadfisher ◴[] No.41866566{4}[source]
Your passkey provider will simply refuse to show that it has a credential for Bob's phishing convincing phishing site. RP challenges are bound to a domain for this purpose.
16. gre345t34 ◴[] No.41866844[source]
If you got tricked into logging into goggle.com or something the FIDO2 auth would fail because a) the URL would not match the credential metadata and b) the resulting assertion, a signature over data which includes the URL, would not be valid (google.com would not accept it).
17. regedit728 ◴[] No.41866906{3}[source]
interesting. unfortunately i don't have as much awareness of ECC as i should have, thanks for the information.
18. lisper ◴[] No.41866925{4}[source]
> you can probably get them to click approve

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.

19. Ferret7446 ◴[] No.41866976{4}[source]
They would have to get you to install a malicious version of your web browser and/or passkey manager, as all legitimate implementations enforce having the correct TLS domain, which is significantly harder than getting you to visit a random URL.
20. bastawhiz ◴[] No.41869995{4}[source]
Your browser won't auth you with a key meant for a site you're not on. There's no mechanism for what you're describing.
21. bastawhiz ◴[] No.41870028{5}[source]
I'd give a key to my bank that they could create signatures with if I asked for (and was authenticated with) that third parties could trust to bypass my passkey. I'd pay a fee for it, the bank holds liability for verifying my identity.

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.

replies(1): >>41870535 #
22. lisper ◴[] No.41870535{6}[source]
OK, so your proposed alternative is to give a key to a trusted third party (TTP). But how do you authenticate to that TTP?