Hacker News Reader

Comment by superzamp | Hacker News Reader

> 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?

View on HN

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.

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

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.

> If one disregards the counter value, they can just outright drop the whole U2F.

It's not pointless. Disregarding the counter only enables replay attacks, that is: the attacker must previously have captured a challenge/response. The phishing resistance is still retained because it relies on the browser passing the origin to the u2f device and the browser can't be fooled by similar URLs while a human entering a TOTO token can.

U2F isn't as trivial to implement as RFC4226 OTP. It takes effort. Implementing the counter check is trivial. Disregarding the counter and stating "that only enables replays" is absolutely unacceptable. If one is so irresponsible to the point they're enabling a replay attack - then there's no excuse and no valid argument to support the use of U2F at all. If you (not YOU, personally) can't implement the protocol fully, don't half-ass it and plant mines. That's my take on it, and anyone who implements this protocol to secure people's accounts MUST (not SHOULD) think the same. There is NO excuse for deliberate irresponsibility.

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.

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/fid...

(Sorry if this comes across as RTFM, but I figured the source is better than my attempt at explaining)

Not at all, the specification is indeed very clear. Thanks for the link!

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.

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.

Reply on news.ycombinator.com