SMS text two-factor authentication "bypassed at scale"

Originally published at:


I’m authenticating right now.


I don’t see how Authy would be any better against this sort of attack. The second factor doesn’t mean anything if the person is just entering the data directly into the phishing site.


Hold on there, am I misinterpreting this? Phishing is social engineering, not a technical problem with the authentication method. It doesn’t matter how good the lock is if someone fools you into giving them the key. I don’t feel like this changes my assessment of how secure two factor security is (or my assessment of how easy it is to fool people).


Humbabella is right. This isn’t bypassing 2FA at all. This is a matter of low attention users handing out their credentials.


The phish here depends on the user expecting and accepting a fake SMS text as part of a 2FA login. If you dont use SMS for authentication, the phish won’t work.


Hey, “Bypassed at Scale”, my favorite '80s boy band!

No, seriously, if I knew who that was, would it be a pun, or just the wrong picture for the article?


I believe the SMS is genuine. Wouldn’t do much if it wasn’t.

Basically, the phisher sends you to a fake page for login. You login, and they pass that login request and password to a legitimate login form. The legitimate login form then triggers the SMS, with a valid code. You receive the legitimate SMS, but enter the code on the fake page. The phisher passes the code on as well, but now they’ve harvested both password and a 2FA code that they can (for the moment) use.


Isn’t any system insufficiently secure as long as people hand out their passwords and and text info to phony site that only looks sorta like google? Until we replace ourselves with bots…

1 Like

It sounds more like it is a man in the middle attack:

They send you to a fake version of the real login page, and they also trigger the sending of the SMS code, then capture it when you enter it into the fake page. Authy will not protect you from that kind of attack if it is automated. They can easily beat the 30 second time out of the time-based one time codes.

What you need is a FIDO hardware key, like a Yubikey or Googles hardware key. They are (currently) immune to man in the middle attacks and can’t be phished.


Assuming they know what kind of 2FA you are using, why couldn’t they harvest that as well? They wouldn’t even need to trigger an SMS from the authenticating site.

1 Like

The whole point is that you should not be using SMS in the first place, because SMS is insecure for 2FA.

You can also be fooled into putting a TOTP token into a phishing site, but the technical aspects of TOTP makes it harder to fool the user and less likely to succeed.

Though there is the thought that once TOTP is the dumbest available form of 2FA, it will be the form of 2FA used by the most easily-phished users.


Because the FIDO standard is engineered precisely to prevent phishing.

Token binding
Token binding is an additional protection supported by FIDO U2F that secures the connection between the browser and the service to prevent man in the middle attacks.

Token binding allows servers to create cryptographically bound tokens (such as cookies, OAuth tokens) to the TLS layer, to prevent attacks where an attacker exports a bearer token from the user’s machine to present to a web service and impersonate the user.Token binding is used by FIDO U2F keys to bind the fido authentication token to the user agents TLS connection with the service.

SMS and Authy can both be phished. Thanks to automation, it’s trivial to beat the expiration of time based one time codes and for hackers to log in to your SMS or Authy protected accounts via phishing attacks. Rob is very wrong about this attack being a recommendation of Authy over SMS. This attack isn’t on a vulnerability of SMS (of which there are plenty). It’s a vulnerability of all 2FA that lacks binding and can be phished.



This sounds like way too much work, until you imagine being paid to hack into the Democratic Party servers, or Weyerhauser, or NORAD. Suddenly you have a pretty good budget to build precise phishing sites, and you can set up a really decent customer service center. They might even think they’re the real customer service.


The way to detect this is to notice how good the customer service is. “Wait a second, these guys are actually responding to my request and helping me… is this a scam?!?”


If it’s Comcast.


As a reminder, preventing phishing starts before the 2nd factor. This kind of phishing attack is an area where a good password manager can help. A password manager like Last Pass (if set right) will only enter your stored Google Password into a Google URL login, not a phishing page with a similar look but a different domain. I expect hackers are working to bypass that protection of Last Pass, but it is one of many lines of defense to consider.

A hardware-based FIDO key is a sound second layer of protection from phishing attacks, since the FIDO keys are expressly designed to prevent phishing. Google helped develop FIDO and requires their employees to use FIDO keys, which Google says has eliminated successful phishing attacks against Google employees. Google, Facebook and a few other sites support FIDO keys.

Protecting your email account from phishing is especially important since your email account is essentially the keys to your kingdom, as it is a prime way to impersonate you, and an easy way to get access to other accounts which will send password resets. The email account can also be used as part of social engineering hacks to get into accounts that won’t just automatically send out a password reset - something I’ve had happen to me. So if you use gmail or Google apps for business, you really, really should use a FIDO key.


Is that what the kids are calling it these days?


This is a broadly effective attack on any 2FA that only authenticates the user to the service but not the service to the user. Which, if I understand what Authy is, then you’re absolutely right, would be just as equally effective at bypassing either method.

To defeat this, you’d need an authentication mechanism where the website authenticates itself to the user (I know, I know, we have one and it’s called SSL certificates, but nobody uses those correctly or we wouldn’t be in this mess).