4 ms·

I can't make sense of your explanation. In 1) I don't think my YubiKey knows anything about the sites I use it for? It just creates keys, so a phishing site co

I can't make sense of your explanation. In 1) I don't think my YubiKey knows anything about the sites I use it for? It just creates keys, so a phishing site could presumably still steal the key created by YubiKey and pass it on to the real site. 2) My fingerprints definitely don't know anything about web sites. So WebAuthn being unphishable has nothing to do with fingerprints. It is only incidental that some devices decide to unlock the functionality with fingerprints.

Thorrez 5y ago
1) The browser tells the Yubikey: "sign this: 'logging in to site.com at 12:34PM'". The yubikey signs it and gives the signature to the browser. The browser gets the signature and passes it on to the site. attacker.com will get a signature over 'logging in to attacker.com at 12:34PM'. That signature will not allow the attacker to log in to facebook.com . 2) Correct. In fact you don't even need a hardware token. You can do the whole thing in software. It could even theoretically be built right into your browser (but you would have the problem of logging in to the account on a different device or different browser). The fingerprint protects against physically stolen devices, and slightly against malware on your computer.
- stavros 5y ago
  I'm still waiting for password managers to add soft-WebAuthn support, so I can log in using my password manager (and no physical keys or passwords). That would make password managers ten times better. Then again, it doesn't have to be the password manager that does this, but it'd be nice if it were integrated.
  - gingerlime 5y ago
    yes exactly! Bitwarden supports TOTP nicely already. And I think you can authenticate to it with FIDO2 apparently. It would be awesome if it could do software-based WebAuthN but I don’t think it does…
    - stavros 5y ago
      It doesn't, unfortunately. I've opened an issue on their forum but nothing yet. Not many websites support WebAuthn (let alone passwordless), so I guess password manager vendors aren't in a hurry to implement it.
- tialaramex 5y ago
  > The browser tells the Yubikey: "sign this: 'logging in to site.com at 12:34PM'" It's even a little bit cleverer than that. During enrollment (to say, Facebook.com) your Yubikey provides a random looking "identifier" to Facebook.com, and it promises that it can sign future logins if Facebook.com shows it the same identifier. The identifier is bound to the DNS name! So a phishing site has a few choices, none of which help the bad guys even a tiny bit: * It claims to be Facebook.com, but it isn't, so the web browser just doesn't even show the UI for Security Keys. There's a behind the scenes Javascript error basically, "What? You aren't Facebook.com fool". * It admits its real DNS name, and makes up a random identifier. The browser gives the random identifier and the real DNS name to your Yubikey. But, it has never heard of this combination, so, it blanks the entire authentication figuring this must be for a different Security Key plugged in on another port or something. * It gets that identifier code for your login from Facebook, and then admits its real name to your browser and provides the identifier taken from Facebook. This still doesn't match, and the Yubikey again assumes it must be for some other Security Key on your system. Behind the scenes this is actually done with AEAD cryptography, maybe with AES keys baked inside your Yubikey. The "identifier" is actually something like a private key (likely elliptic curve parameters) that has been encrypted using an onboard secret AES key in an AEAD mode, with the DNS name (well, a hash derived from it) as a factor. As a result, your Yubikey can't even decrypt the "identifier" correctly in order to log you in without the matching DNS name. This means goofs in the implementation fail safe - e.g. one brand of cheap Security Keys can fail to sign in once every 256 tries on average due to a logic bug. But they'd never sign in where they shouldn't because of mathematics, to do that they'd need to "accidentally" completely break the mathematical foundations of the cryptography!
kerng 5y ago
At high level imagine it like this: The browser will only give access to the Yubikey token for a specific domain name - so if the attacker phishes for examle.org, rather then example.org, then there is just no tokens (signing keys) available the Yubikey could use and give to the browser. In the early days WebUSB in Chrome had bugs that allowed to bypass that same origin check but that has been fixed 3 years ago.
- notanzaiiswear 5y ago
  I've been using the browser's password manager as protection against phishing, as the password manager won't fill in passwords on the wrong site. So I guess it works in a similar way with the Yubikey? OK.
  - kerng 5y ago
    At a very very high level yes - but the reason you want to use tokens is that you get a second factor and you have better entropy and created tokens are time based (password is valid forever).

Thorrez 5y ago

1) The browser tells the Yubikey: "sign this: 'logging in to site.com at 12:34PM'". The yubikey signs it and gives the signature to the browser. The browser gets the signature and passes it on to the site. attacker.com will get a signature over 'logging in to attacker.com at 12:34PM'. That signature will not allow the attacker to log in to facebook.com . 2) Correct. In fact you don't even need a hardware token. You can do the whole thing in software. It could even theoretically be built right into your browser (but you would have the problem of logging in to the account on a different device or different browser). The fingerprint protects against physically stolen devices, and slightly against malware on your computer.

stavros 5y ago
I'm still waiting for password managers to add soft-WebAuthn support, so I can log in using my password manager (and no physical keys or passwords). That would make password managers ten times better. Then again, it doesn't have to be the password manager that does this, but it'd be nice if it were integrated.
- gingerlime 5y ago
  yes exactly! Bitwarden supports TOTP nicely already. And I think you can authenticate to it with FIDO2 apparently. It would be awesome if it could do software-based WebAuthN but I don’t think it does…
  - stavros 5y ago
    It doesn't, unfortunately. I've opened an issue on their forum but nothing yet. Not many websites support WebAuthn (let alone passwordless), so I guess password manager vendors aren't in a hurry to implement it.
tialaramex 5y ago
> The browser tells the Yubikey: "sign this: 'logging in to site.com at 12:34PM'" It's even a little bit cleverer than that. During enrollment (to say, Facebook.com) your Yubikey provides a random looking "identifier" to Facebook.com, and it promises that it can sign future logins if Facebook.com shows it the same identifier. The identifier is bound to the DNS name! So a phishing site has a few choices, none of which help the bad guys even a tiny bit: * It claims to be Facebook.com, but it isn't, so the web browser just doesn't even show the UI for Security Keys. There's a behind the scenes Javascript error basically, "What? You aren't Facebook.com fool". * It admits its real DNS name, and makes up a random identifier. The browser gives the random identifier and the real DNS name to your Yubikey. But, it has never heard of this combination, so, it blanks the entire authentication figuring this must be for a different Security Key plugged in on another port or something. * It gets that identifier code for your login from Facebook, and then admits its real name to your browser and provides the identifier taken from Facebook. This still doesn't match, and the Yubikey again assumes it must be for some other Security Key on your system. Behind the scenes this is actually done with AEAD cryptography, maybe with AES keys baked inside your Yubikey. The "identifier" is actually something like a private key (likely elliptic curve parameters) that has been encrypted using an onboard secret AES key in an AEAD mode, with the DNS name (well, a hash derived from it) as a factor. As a result, your Yubikey can't even decrypt the "identifier" correctly in order to log you in without the matching DNS name. This means goofs in the implementation fail safe - e.g. one brand of cheap Security Keys can fail to sign in once every 256 tries on average due to a logic bug. But they'd never sign in where they shouldn't because of mathematics, to do that they'd need to "accidentally" completely break the mathematical foundations of the cryptography!

kerng 5y ago

At high level imagine it like this: The browser will only give access to the Yubikey token for a specific domain name - so if the attacker phishes for examle.org, rather then example.org, then there is just no tokens (signing keys) available the Yubikey could use and give to the browser. In the early days WebUSB in Chrome had bugs that allowed to bypass that same origin check but that has been fixed 3 years ago.

notanzaiiswear 5y ago
I've been using the browser's password manager as protection against phishing, as the password manager won't fill in passwords on the wrong site. So I guess it works in a similar way with the Yubikey? OK.
- kerng 5y ago
  At a very very high level yes - but the reason you want to use tokens is that you get a second factor and you have better entropy and created tokens are time based (password is valid forever).