Hacker News Reader

Comment by trash_panda | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com