Hacker News Reader

Comment by sytse | Hacker News Reader

Do the security keys prevent phishing because they will only login to the same site by checking the domain? So you can't mitm someone.

View on HN

U2F incorporates the origin, which prevents phishing (unlike TOTP 2FA)

Thanks!

They don't actually "prevent phishing" per se, they just make it ineffective. Users can still get phished if they use a hardware or software 2FA.

The thing is, if you fall victim to a phishing attack, the attacker may steal your credentials; but he/she will not be able to login to your accounts because even though the username and password works, they still need to have the 2FA code which only you have in your physical possesion (wheter it be a Yubi Key or a OTP in your phone). So the attack will be unsuccessful.

On the other hand, you could still get infected with malware via a phishing attack if you don't have a secure system. In this case, 2FA won't help much.

U2F actually does prevent phishing since the domain is included in the token generation.

I understand that, but let's say I try to phish you with a fake login page. Of course, the Yubikey won't send the code to that fake page as the domain name doesn't match, but an unsuspecting user could still enter his/her credentials into the fake form. As I said, the attacker may not do much with those credentials if every system uses 2FA, but they may be useful some day :)

Would it be possible to reverse order?

I mean: 2fa-code, login, password instead of: login, password, 2fa-code. Maybe login could be automatically filled based on 2fa-code public key? That should prevent leaking password to fake page.

You need the login first.

A cheap Security Key has no idea what public key it told you to use when registering.

There's a cute trick here. When you tell a key "Hi, authenticate please" you must send it a "cookie" it gave you during registration. Now this could in theory be some pointer it uses or whatever. But in fact it's actually the private key it will use to authenticate, encrypted with its own baked in secret key. It decrypts that, then authenticates. But if you don't know which user you're authenticating you can't send their cookies, you'd have to try every cookie for every user. Not fast.

If every user uses WebAuthn then just a login (username or email address or something) is enough. But if some just have passwords then doing anything before the password step gives away what's up.

An interesting solution could be to first enter the username, then the OTP/Key, then the password. I haven't given it a lot of thought and can't find anything wrong with it.

Like GP said, that would give away which accounts have WebAuthn enabled on them, since those without it would send you straight to the password prompt instead.

But more importantly, phishing sites will always tell you 'your key succeeded. Enter your password next' regardless, so this doesn't protect against password disclosure at all.

Nope, because you'd be relying on the fraudulent phishing page to tell you that.

Real page: Give me login You: Login Real page: Good login, press your 2fa to authenticate You: Press Real page: Good 2fa, enter your password You: Password

Versus:

Fake page: Give me your login You: Login Fake page: Good login, press your 2fa to authenticate You: Press Real page: Good 2fa (wink wink), enter your password You: Password

The fake page wouldn't have a working login to the real page because the 2fa would be wrong, but it would still have your password.

You can still get phished, and have your password be stolen. It just doesn't allow you to login in to the FIDO protected resource. Other endpoints might still work if they dont' require FIDO or you reuse the password.

The keys are completely happy to authenticate to every site, the cheap ones have no memory so they have no idea which sites you use.

So mybank.phishing can ask your Security Key to please authenticate, and convince you to press the button, but the output is useless for getting into the real site at my bank.com

Not only is a valid authentication to PornHub useless for GitHub, even if they both collaborate and share all their data they can't prove you've used the same token for both sites, so this is even a privacy win.

This is important to note : you don't need a hardware key to prevent phishing this way. This all could be accomplished with software.

However, unless there is specialist hardware (which might be baked into your iPhone etcetera rather than a separate token) there's a risk bad guys steal the secret key via another route and then you're in a world of pain.

Secret Key USB or NFC devices also more resemble other physical keys for which users already have some useful intuitions we can leverage.

You can still hack the U2F software in the browser and steal the key. If an attacker is local, the game is over. The only thing the button does is limit how many opportunities the attacker has.

Almost all practical attacks are against a key stored on a server somewhere, a key in flight on the network, or a lack of security in the client. If we properly secure these aspects of access, we don't need a whole lot of extra layers, which are only workarounds for the actual root problems.

"Steal the key"? Steal WHAT key?

In the cheap mass-produced FIDO tokens we mostly care about the only keys anybody is storing are 1. a single secret symmetric key inside the token. It has no reason to give this up to anybody, and no API for doing so; 2. _public_ keys used to check credentials

If you're thinking "Wait, that can't be right, where do the corresponding _private_ keys live?" then Bzzzt, time to go read the FIDO/U2F specification before writing anything else on Hacker News.

The whole point of this type of design is that even if the attacker has local code execution you haven't lost. An attacker with local code execution _plus a button press_ gets not a key which can be stolen but a single proof of control of their choice. It's like stealing a single OTP code, it's not _nothing_ but it's very far from everything.

Even if you phish their password to a site, the person can't log in because they also need the physical key. The key doesn't validate anything related to the domain AFAIK

That would be useless, as the key could just be passed through.

What do you mean "passed through"? You can't just steal a key and replay it whenever you want. (Unless you physically steal the key)

But you can trick Bob into entering his credentials + using his security key on corp.bank.co.m and then use those credentials + security key interaction to log into corp.bank.com IF the security key interaction is domain agnostic (like you can do with the 2FA codes you get on your phone - if you can trick Bob into entering his password you can trick corp.bank.com into sending Bob a 2FA code which he will also give you).

U2F key interaction is not domain agnostic. That's why it's so good against phishing--it can't be collected by a fake domain to pass through to the real one.

The key requires physical feedback, the user needs to push the button when prompted by the software and that button pushing will only authorize a single authentication.

Reply on news.ycombinator.com