4 ms·

> The value proposition of a U2F device like the YubiKey is that not only must you have it present, it's not subject to the TOTP being disclosed like with token

> The value proposition of a U2F device like the YubiKey is that not only must you have it present, it's not subject to the TOTP being disclosed like with tokens that require the user to enter a password into a third-party service which could still be a phishing page Could someone shed some light on this? What is it that prevents a phising page from basically proxying the crypto challenge from the website to your key and present your answer back?

mimming 8y ago
Essentially it borrows the protections from TLS. Here's a link to the relevant part of the spec: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#man-in-the-middle-protections-during-authentication https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid... (Sorry if this comes across as RTFM, but I figured the source is better than my attempt at explaining)
- superzamp 8y ago
  Not at all, the specification is indeed very clear. Thanks for the link!
  - Boulth 8y ago
    Channel ID has been depreciated and replaced by Token Binding but I'm sure U2F sites don't use either. The real protection is quite simple: incorporating the origin (domain name) in the protocol. So phishers would get a bad response from the token.
BillinghamJ 8y ago
The origin of the page is part of the signed payload. So if another website presented the challenge, the origin part wouldn't match. That does assume the thing communicating with the security key is not compromised though (the browser/OS). Not entirely sure about how Google Smart Lock on iOS works in this regard - since it communicates over BLE and could specify any origin, and then the process of going between the app/web on iOS can't be secured particularly well. Also unclear how origins would work with regards to non-web applications. e.g. URL schemes aren't unique/owned/defendable.
furicane 8y ago
U2F is a two step process - you need to register the device first (through challenge-response process called ENROLLMENT), then you can use it by issuing authentication challenge (U2F authentication is NOT the same as user authentication, they labeled the process as ENROLLMENT - AUTH process). During registration you receive several pieces of info, such as keyHandle, public key you use to verify future device responses and an attestation certificate so you can verify the device vendor. The interesting part is this: when you challenge the u2f device to sign AUTHENTICATION request, what it does is keep a counter tied to your appId (the domain where the .js that deals with this is executed) and it produces encoded json which is signed by the device, using an EC private key. The counter increases every time the device is challenged by that particular appId. The response is signed using the counter and a private key that's on the device (which you can't tamper with). So, the phishing / mitm should have the value of private key and the moving part (counter) that's tied to a specific appId. That's difficult since it SHOULD do this during enrollment process and every subsequent authentication request. What's important that not only does it protect against phishing but from replays too. Naturally, the u2f device isn't standalone responsible for this, the verifying server implementation is a crucial part of the process. Disclaimer: I'm not affiliated by Yubico, but have implemented U2F (the dreaded js part and backend part) in 2015, several months after Chrome 38 has been released, the first version supporting u2f protocol.
- gst 8y ago
  Last time I checked (more than a year ago) most of the websites didn't care about the counter value. (If you use a Ledger device for U2F and subsequently restore a new (or a reset) device from your private seed the counter will be reset. Trezor has the same issue but allows you to manually set the counter to work around it.)
  - furicane 8y ago
    I haven't got any info on websites caring about the counter value. It seems.. pointless to use U2F if you just disregard the counter value. You need to extract it from the response in order to construct the binary data to verify the signature. If one disregards the counter value, they can just outright drop the whole U2F.
ecesena 8y ago
The hostname of the website you're visiting is cryptographically signed by the security key. So, if by accident you're on phishing.com, the key will generate a signature containing phishing.com. When the attacker forwards it to google.com, Google won't verify the signature, and thus the attacker won't get access to your account.

mimming 8y ago

Essentially it borrows the protections from TLS. Here's a link to the relevant part of the spec: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#man-in-the-middle-protections-during-authentication https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid... (Sorry if this comes across as RTFM, but I figured the source is better than my attempt at explaining)

superzamp 8y ago
Not at all, the specification is indeed very clear. Thanks for the link!
- Boulth 8y ago
  Channel ID has been depreciated and replaced by Token Binding but I'm sure U2F sites don't use either. The real protection is quite simple: incorporating the origin (domain name) in the protocol. So phishers would get a bad response from the token.

BillinghamJ 8y ago

The origin of the page is part of the signed payload. So if another website presented the challenge, the origin part wouldn't match. That does assume the thing communicating with the security key is not compromised though (the browser/OS). Not entirely sure about how Google Smart Lock on iOS works in this regard - since it communicates over BLE and could specify any origin, and then the process of going between the app/web on iOS can't be secured particularly well. Also unclear how origins would work with regards to non-web applications. e.g. URL schemes aren't unique/owned/defendable.

furicane 8y ago

U2F is a two step process - you need to register the device first (through challenge-response process called ENROLLMENT), then you can use it by issuing authentication challenge (U2F authentication is NOT the same as user authentication, they labeled the process as ENROLLMENT - AUTH process). During registration you receive several pieces of info, such as keyHandle, public key you use to verify future device responses and an attestation certificate so you can verify the device vendor. The interesting part is this: when you challenge the u2f device to sign AUTHENTICATION request, what it does is keep a counter tied to your appId (the domain where the .js that deals with this is executed) and it produces encoded json which is signed by the device, using an EC private key. The counter increases every time the device is challenged by that particular appId. The response is signed using the counter and a private key that's on the device (which you can't tamper with). So, the phishing / mitm should have the value of private key and the moving part (counter) that's tied to a specific appId. That's difficult since it SHOULD do this during enrollment process and every subsequent authentication request. What's important that not only does it protect against phishing but from replays too. Naturally, the u2f device isn't standalone responsible for this, the verifying server implementation is a crucial part of the process. Disclaimer: I'm not affiliated by Yubico, but have implemented U2F (the dreaded js part and backend part) in 2015, several months after Chrome 38 has been released, the first version supporting u2f protocol.

gst 8y ago
Last time I checked (more than a year ago) most of the websites didn't care about the counter value. (If you use a Ledger device for U2F and subsequently restore a new (or a reset) device from your private seed the counter will be reset. Trezor has the same issue but allows you to manually set the counter to work around it.)
- furicane 8y ago
  I haven't got any info on websites caring about the counter value. It seems.. pointless to use U2F if you just disregard the counter value. You need to extract it from the response in order to construct the binary data to verify the signature. If one disregards the counter value, they can just outright drop the whole U2F.

ecesena 8y ago

The hostname of the website you're visiting is cryptographically signed by the security key. So, if by accident you're on phishing.com, the key will generate a signature containing phishing.com. When the attacker forwards it to google.com, Google won't verify the signature, and thus the attacker won't get access to your account.