8 ms·

I don't see how passkeys do anything to prevent phishing.

by scherlock 2y ago

bastawhiz 2y ago
How exactly do you get someone to give their passkey private key to a bad actor?
- scherlock 2y ago
  "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.
  - tadfisher 2y ago
    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.
  - bastawhiz 2y ago
    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.
lisper 2y ago
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.
- scherlock 2y ago
  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.
  - lisper 2y ago
    > 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.
  - Ferret7446 2y ago
    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.
sitharus 2y ago
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.
gre345t34 2y ago
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).

I don't see how passkeys do anything to prevent phishing.

bastawhiz 2y ago

How exactly do you get someone to give their passkey private key to a bad actor?

scherlock 2y ago
"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.
- tadfisher 2y ago
  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.
- bastawhiz 2y ago
  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.

lisper 2y ago

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.

scherlock 2y ago
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.
- lisper 2y ago
  > 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.
- Ferret7446 2y ago
  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.

sitharus 2y ago

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.

gre345t34 2y ago

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