Hacker News new | past | comments | ask | show | jobs | submit login

> Yubikeys are great for security, but not when you leave them in your computer unattended. At that point, anyone can take the key and use it for 2-factor authentication/SSH/GPG signing, so it’s not much better than just using a normal password.

Even after the edit at the top regarding PIN it still seems to not get the main point of a U2F token: It's physical. It's incredibly hard to extract secrets from it. It's local to where it physically is.

If I have a password then there are probably a couple of services and people that could reasonably get to it either by hacking the service the password unlocks (in storage if its a really insecure service or in transit the next time I log on), or can extract it from my password manager/memory/browser or whatever.

The point of a U2F token for me is to change the number of people who can reasonably authenticate as me from "everyone who has my password" to "everyone who have a physical key I keep within a reasonable distance from me that is incredibly hard to copy and has my password". U2F also validates auth origins quite a lot better than many other methods, although I guess that is not relevant to this argument.

A hardware U2F token is not the end-all be-all security, but it reduces potential attackers a lot.

In this context it's probably better to think about them as FIDO/ CTAP tokens rather than as U2F (which is obsoleted by WebAuthn and focused on the Web) or, as the author does, just narrow it explicitly to Yubikeys and not the wider menagerie of similar products. Yubico's own Security Key implements FIDO2 (and so could also be used for U2F) but won't work for the author's approach.

Anyway, the main thing I wanted to mention is that the use of public key encryption means this is quite different from the device having "my password". Even in the on-device ("resident credential") scenarios the authenticator doesn't have a password which is a shared secret, it actually has a private key which it won't divulge - much better.

Implementation errors by a web site can leak your password, which because it's a shared secret can then be used by adversaries to log in. It's impossible to be sure a site didn't get this wrong, even if you're confident they are competent and well meaning.

In contrast the WebAuthn (and U2F) design doesn't give sites enough information to impersonate you even if they wanted to, only to authenticate you. This is a familiar pattern from public key cryptography, receiving the certificate for news.ycombinator.com allows me to verify this is news.ycombinator.com but not impersonate them. Likewise, when you enroll a FIDO authenticator to use Facebook, Facebook doesn't learn how to impersonate you, even on Facebook, only a way to verify that you still have that authenticator. [And the design is even more careful, it uses completely independent credentials for each site, so when Microsoft bought GitHub they actually could not merge the FIDO-based authentication between GitHub and Microsoft properties, even if they thought that was a good idea it's deliberately impossible. ]

Is any of that a contradiction of what I said or are you providing context?

On re-examination of what you wrote I think I misinterpreted this sentence:

"everyone who have a physical key I keep within a reasonable distance from me that is incredibly hard to copy and has my password"

I took (hard to copy and has my password) to be properties you were giving the physical key, but in fact I see the correct interpretation was that "and has my password" is an adjunct to the properties of this hypothetical attacker who now needs to steal the key.

Yeah, I meant "(has the key) and (has my password)", not "has my key which has my password". The reply makes a lot more sense now, thanks for the clarification! I'll try to be more unambiguous.

Honestly the threat of someone cloning the key is so minor that a USB stick is probably enough. If someone goes through the effort to make fake a USB stick with the right hardware ids then I've got way bigger problems.

If you are talking about a U2F usb stick I agree with you (I put "incredibly hard" instead of "impossible" there so that I don't get counterarguments with people reading memory with electron microscopes or similar).

If you are talking plain USB mass storage for keys I disagree.

For most of us, the inability for the key to be duplicated remotely is the primary design criteria, as most of us need to defend against low to moderate remote attacks (which is exactly SMS 2FA is bad). You have to be an incredibly high value target before "my opponents are willing to send people to try and steal my 2FA token from my person and clone it" is a probable risk. At that point you better be using all kinds of special equipment and techniques, as a Yubikey alone probably isn't enough.

That being said, it's incredibly unlikely that someone would ever sell mass storage based USB credentials because:

1. Security products are marketed based on surviving the worst case scenarios. Nobody would buy a U2F token that is "good enough for the threats you probably face".

2. By the time you've hardened any USB device from remote cloning, you're probably already done most of the work to harden it against local cloning. Might as well complete the last bits necessary in order to get the marketing benefits from point 1.

From what I can read we don't disagree about anything

USB mass storage based authentication also does not protect against malware stealing the keys. A YubiKey (or similar token) performs all of the cryptographic operations in a separate environment that malware cannot access.

Yes, that would be a “remote copy” since it doesn’t require physical access to the u2f token.

never use absolutes on the internet.

(it's kind of funny how you can make a seemingly airtight argument about something common-sense and non-controversial and have some weird imposs.. improbable corner case unravel everything)

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact