Hacker News Reader

Comment by laurencei | Hacker News Reader

Does 2 factor prevent phishing though?

If I was going to do a Google Phishing page - I would take the username + password that the user supplied into MY fake page, and POST/CURL that to the Google login.

If Google returns asking for a 2factor to MY fake, I would display the 2 factor prompt to the user, and get them to type the 2-factor into my page, which I would pass back to Google.

Basically you can use a phishing page as a MITM attack.

When you auth against Google with 2-factor, there is a "remember this computer" option - giving the attacker at least 30 days of access to your email without needing a further 2-factor code.

So if the person is tricked enough to type their username+password into a fake google page, they are just as likely to follow through with their 2-factor code.

View on HN

This is where the type of MFA matters a lot: with a TOTP code, that phishing attack will be successful.

With U2F, however, a per-host keypair is generated during the setup process and the public key is given to the remote server. Critically, the hostname as seen by your browser is part of the key identifier: see http://security.stackexchange.com/a/71704/311

That means that if in the future even if someone convinces you to visit their phishing site and activate the token, the login attempt will still fail because the hostname as seen by the browser won't match a key on the token.

But can't the phisher just visit Google and log in there with 2FA, while receiving the 2FA code from the fake site?

This only requires the user not to read the URL and match it to the URL in the Google Authenticator app (as far as I can see right now).

It depends on which 2FA method you use, and there's an associated time window. The TOTP method (Google Authenticator App) of a rotating number must be used within a window of at most a few minutes -- new numbers are generated every 30 seconds, so they could use that if they logged in immediately.

If you use U2F, then the domain name difference will mean that the U2F key can never match unless the attacker has control over DNS and is issued a Google.com SSL certificate by an authority the target's computer trusts.

As acdha said, no, this type of attack isn't possible with U2F.

If a server is making the proxied request, would this still matter? The server will pretend to be a legit browser submission? In your link they mention reply. But what about a browser you control on the server?

Your browser connects to Google and tells the U2F token to auth using the www.google.com key: works

Your browser connects to www.google.com@phish.me but no matter whether you believe that site to be Google, the U2F process means that it can only use a key for phish.me, which won't work on the Google.com servers even if they relay it.

The only attack which still works is if they control DNS and can forge an SSL certificate, at which point we have much bigger problems than phishing.

> The only attack which still works is if they control DNS and can forge an SSL certificate

Or if they're able to get some malware onto your system permitting them to change your dns servers or alter your hosts file, and add certificates to your OS/browser trust store.

Both of those fall into “control of DNS” or “forging an SSL certificate”. Besides, if they can do either of those things they don't need to phish you because they can just hijaack your existing browser when you login to the real site.

Sure, but that's raising the bar a hell of a lot higher than where it is currently, where all you need is a HTML email message that happens to superficially resemble something a random person might expect Google to send.

And in the long run I have more faith in making systems more secure via technological means than to try and convince users not to click on links in shady email messages. So by moving the problem into the technology domain and out of the social domain, I'd say it's a big win.

I have been working on stopping phishing for the last year and have read many malware analysis reports. Domain whitelisting will make it much harder for the attackers.

I just announced beta of host based DNS whitelisting app. It trusts top 10,000 domains, then user has to allow other domains.

https://twitter.com/mabraFoo/status/790678093618900993

Under FIDO U2F, the token and website authenticate each other.

You're right, though, TOTP is not enough.

To be clear, there is no real mutual authentication between the server and the token. The server can authenticate tokens (after first registrations) but not the other way. (You have to get outside FIDO U2F specifications if you want to do so.) With standard FIDO U2F USB tokens, the server authentication is done through SSL on the client application level (most of the time : a web browser).

Reply on news.ycombinator.com