Hacker News Reader

Comment by pvg | Hacker News Reader

There's two keys here and some adapters. It costs the same, or a bit less than buying your own keys individually. These counter phishing better than TOTP.

View on HN

How do hardware keys counter phishing better than TOTP?

Codes can be replied. Security keys cryptographically sign the hostname, so the credentials generated can't be used across different domains.

This is a short edu video, I'd be curious if you have any feedback: https://twitter.com/_conorpp/status/1036751355346595840

Phishing site has no access to the additional auth info. With regular 2FA mechanisms, you type that into a browser.

With a security key, how does it get from the usb device to the browser? The token I used for my last work (I think it was a yubikey) appeared to the computer as a keyboard, and activating the 'button' on it simply sent a bunch of letters into an input field in a browser. This would be susceptible to phishing in the same way, no?

"Hardware security key" has come to mean "U2F key".

Older hardware keys (include Yubikeys in OTP mode) didn't do any better at preventing phishing than TOTP. But U2F keys do; they generate credentials that are cryptographically bound to site origins, and work out-of-band from the keyboard. They were designed specifically to combat phishing.

Oh! So the OG USB keys were OTP thingies that just did the typing for you? I had no idea.

Yeah, but even before that there were things you might call a "security key" (but which most people called "hardware tokens") that just displayed a single TOTP-like code; if you talk to enterprise people about security keys, those SecurID tokens might be what they're thinking about.

Your example would be valid if U2F simulated a keyboard, but it doesn’t. The U2F key is a non-keyboard USB-HID device. The browser has special code embedded to identify and communicate with U2F keys using low level operating system USB api calls. The authentication process is a challenge response mechanism where the site challenges and the key signs and responds to the request. The browser adds an additional piece of information to the challenge and embeds the actual URL (and tls session id if supported) and the server verifies this additional information. Phishing and mitm are prevented because the server is validating the actual URL of their own site when checking the signed response. The whole process is really cool when you get into the details and is very well designed for security.

Reply on news.ycombinator.com