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.

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 [email protected] 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).

I'm waiting for the day in which I can sign up for 2FA without giving my phone number. At this point, I believe they are holding it on purpose, as my phone number is a much more reliable unique identifier than my username and/or cookies.

(Yes, you can use the Google authenticator, but no, you can't do it if you haven't given your phone number first)

Edit: by "they" I mean GMail - other sites work just fine.

To use google authenticator you do not need to give out your number. Most sites will have a qr code you can scan with your phone and the google authenticator app uses that to generate 2fa codes that are valid within a certain time frame.

I just checked. The first screen I got says "Step 1/3: we'll either call you or send you an SMS. Please give us your phone number".

You cannot skip this step on GMail, or at least I couldn't find how. I know you can use the app afterwards, but not before.

Other sites just give me the code, as you say. But not GMail.

You can rent a burner SMS number for a couple bucks on a site like https://smsprivacy.org/

You could create a Google Voice account with a free number and link to that. Set it up so calls/sms/etc go nowhere but can be changed if you need to restore your Gmail account later with that number.

How recently have you tried to do so? I tried a couple of months ago to set up a Gmail account with a Google Voice number for verification, and it refused to let me with a message which I recall as being vaguely like "This is not an acceptable verification number".

The workflow does not, and so far as I can tell, never has, support this. I've commented on it for years at G+.

Well, on a phishing page the user could still type in the username and password before clicking submit. Only after submitting the username and password do authentication layers require the user to interact with their mobile device (which is usually how it works). Some users might forget that they are supposed to 2FA (say, on their first few days at the job).

What if the password input would only be shown after the user typed in their username, pressed submit and confirmed that they were trying to log in using their mobile device?

* Input username

* Press submit

* Interact with mobile device for 2FA

* Input password

* Press submit

Adding 2fa does not completely close the exploit window, but it does reduce it considerably. Even if the phishing page prompted for 2fa, those credentials would only be valid for the next ~60-120 seconds, so any attack would have to be staged very quickly.

In this example, they waited three days before trying to utilize the broken account; with 2fa they would not have that luxury.

And this (asking for 2fa in the phishing page) would entail a risk as well; if they prompted a user who did not have 2fa for their 2fa credentials, then they would immediately be (at best) confused, and possibly suspicious, so they would have to decide to take the risk as to whether to attempt to target 2fa'ed accounts. And if they don't offer a 2fa prompt, then the phishing attempt has fizzled, as even with the password, they only have one factor.

Any sort of re-ordering of the login process by the good guys is only effective if the customer is extremely suspicious of changes in the login process, which nobody will be. The phishing site is under no obligation to match their flow to that of the faked website unless not matching by itself would be suspicious.

Why couldn't the attacker page pass on the 2fa token immediately to Google and log in as the victim? Then the attacker would have a month or so, not 30 seconds, with which to abuse their account

That's why I said that it narrowed the exploit and what I meant by "[staging] very quickly". It's a more narrow window, and the other objections (like prompting non-2fa users for 2fa) still apply.

If a human has to be involved on the attacker side, then this gets tricky, since they only have a short window where the 2fa is valid. If an automated process is trying to log on, then it is possible that CAPTCHAs would either prevent getting a full interactive session (i.e. just a "read email" level of access, as for an app) or block the attack entirely.

If you are a MITM you don't have to prompt non-2fa users for 2fa. You just replay their credentials, live, on the real site, and if the real site is asking you for 2fa, then you ask the real user for their 2fa.

I think the point here is that, even if you give away your password, the attacker won't be able to access your account, because you're protected by 2FA.

If 2FA was supposed to protect your password from being phished, then it would have to prompt you for your 2FA code every time you log in, which would be pretty annoying.

And even that isn't good enough when you get mitmd.

If you accidentally delete the Google 2FA app, or your phone is stolen / lost, you have to regenerate all the tokens, which can be quite a pain. This happened to me once, and I was lucky I had several 'recovery codes' which I then used to reset the tokens. Personally I would stay clear from a Google-issued 2FA app as they have more reason to track you and the services you use.

Go for something like FreeOTP: https://freeotp.github.io/

Also 2FA can sometimes be overkill, especially if you're constantly logging into accounts which you know will get old and dusty over time (think Yahoo Mail for example)

It's Yubikey.

Google Authenticator doesn't do any kind of push notification when you log in. Each endpoint uses a shared secret (the server and the mobile app share that secret beforehand) to generate a time-limited code.

Actually I was talking about another method:

http://lifehacker.com/google-prompt-lets-you-use-two-factor-...

Essentially its like 2 factor auth, except you arent conveying codes from your phone to the computer.

This is a nice feature because it is a lot more user friendly than normal 2fa, it's free if you have a smart phone and well, it works.

op isn't talking about totp, it's the push notification you get when you log in on a new device (the "review your recent login" notification)

op is talking about "Google prompt".

See here: http://arstechnica.com/gadgets/2016/06/googles-new-two-facto...

oh nice, that's even better

I don't think I'd call what Google does 2-factor authentication. Unless I'm missing some option to change this behavior, it's still 1-factor, but what changes when you enable it is which factor is the fundamentally required one. With it disabled, you have one factor, the password; anyone who gets it can log on. With it enabled, the password is no longer the single factor, but it is also no longer a required factor at all, because the password-reset mechanism goes through the same phone number used for the 2fa SMS pushes. So now the phone (or more specifically, ability to receive SMSs to the saved number) becomes the single factor. To be actual 2fa, someone in possession of only one of the two factors shouldn't be able to override the other factor.

There are obvious reasons Google does it this way, and it is probably a net increase in security, because a phone as a single factor is less often compromised than a password as a single factor. But I don't like calling that particular arrangement 2fa.

Also, you can steal someone's phone account in about a hot minute. Watch:

https://youtu.be/bjYhmX_OUQQ?t=98

This phishing test company has one of their employees steal a reporter's cell phone and it's amazing. She basically plays a crying baby on youtube and just grabs the account without knowing anything...

(posted by @nbadg https://news.ycombinator.com/item?id=12598989 )

2FA using a phone number isn't really 2FA, as you've said. There's a reason this method has been deprecated by the NIST and other folks making recommendations about this.

Used correctly, their TOTP app is a real second factor, because it only lives on a single device that you have.

To be precise: Google's hardware 2FA support will work with any security key supporting the FIDO U2F protocol.

Yubikey devices are U2F compatible. (And in my opinion one of the best devices out there, thanks to PGP/SSH smartcard support.) But there are also cheaper versions on Amazon that work just as well if you're on a budget.

https://tozny.com/ sells a service that enables this for any app, not just Google.

I have a Yubikey and I find it too obnoxious for day-to-day use. I'd rather use an authenticator app (such as Google's or LastPass').

For TOTP on non-Google sites, I find LastPass better than Google's Authenticator. First, LastPass locks the app with a PIN. Second, it can work with the browser extension to fill out those 6-digit codes for you.

https://duo.com/ also provides a service (with free and paid tiers) to enable this in a range of applications.

Shouldn't Google easily be able to mitigate a login from Africa (or just a different country or even a never-before-used IP)?

It looks like they had control over some servers in the US. Perhaps they logged in from those remote servers?

they can, and they do. as TFA noted, there was a bounce in the US.