Hacker News Reader

Comment by pmoriarty | Hacker News Reader

My main concern is getting access when the security key breaks or I lose it.

For this, it's imperative that there's either another way to get access or that I associate a 2nd security key with the service I need access to. Of course, it's possible that the 2nd key breaks or is lost.

At least with hard drives, it's common for two hard drives manufactures around the same time to fail around the same time, so I'd be concerned with the possibility of that happening with the two security keys as well.

View on HN

Use TOTP as a fallback.

You might argue "well why bother with U2F, if you are going to set up TOTP anyway", to which I respond that using U2F is still a net win, because for the times you use U2F, you are safe from phishing attacks.

That in an emergency situation you have to use TOTP, and thus be vigilant that you aren't being phished, does not negate the benefits from having used U2F previously.

I can see that by enabling TOTP as a second-factor, it increases your attack surface. That is, you now have to care about whether your TOTP secret has been leaked. I consider this cost to be small, compared to the benefit of being able to fallback to TOTP. Others may decide this tradeoff isn't worth it.

It's still not clear to me how u2f prevents phishing. If I was being proxied through a site with a valid tls cert, they still gain my password and a session key.

U2F keys are linked to the associated domain (e.g. google.com or dropbox.com), so your U2F would not present your google.com key to a U2F prompt on googlehax.com

This stops the proxy attack you describe getting a session key, but not getting your password. Of course, the password alone is insufficient.

To clarify, the U2F key never leaves the device; only a signature.

In what sense are the keys linked? I'm assuming it requires the browser to pass the actual domain requesting the auth?

The browser passes the origin (protocol + hostname + port) to the key. This field is included in the data the key signs. The signature would not match for an authentication response obtained via phishing because of that.

Your original description is a bit ambiguous: were you referring to a case where the actual domain was being successfully man-in-the-middle'd with a valid TLS certificate? That's not something U2F aims to solve (and not something that people generally refer to as phishing).

Edit: Small correction: U2F makes use of TLS ChannelIDs, which, if I understand correctly, would help in that scenario (MitM with a trusted-but-attacker-controlled certificate on the "real" origin). I'm not sure if anyone other than Google makes use of this yet, as it requires a new TLS extension on the server.

No, you answered my question. I accepted that any/most/all authentication breaks down in some way of you can't trust tls certs or the browser/user agent.

I have 2 keys, one stored in a safe place. They are cheap enough that you can have several, but then it becomes a challenge to keep your various accounts up to date. I wish that openid was still well supported as I would like to have one authentication provider for all my online accounts.

> I would like to have one authentication provider for all my online accounts that I control and trust.

Ftfy

So, when you join a new site that supports U2F do you have to retrieve your "extra" key and join it to the site? That seems quite fragile and fraught with danger. :(

But you wouldn't be using both hard drives at the same time. You put one in a safe (place) and only take it out for the occasional setup, maybe swap them every couple months.

This holds true for any 2FA solution, and is generally solved by services that use this kind of technology (e.g., in the form of FIDO U2F) to allow you to register more than one device (so you can have a backup key) and crucially, to allow you to generate a large set of security codes that can be used once to reset access to the service. These codes you would ideally print out and store with your other valuables, or backup in some other manner not dependant on your security keys.

Reply on news.ycombinator.com