This is not the first time that security of Twitter authentication has been called into question. There was the dump of 55K passwords from May 2012, and more recently another quarter-million Twitter accounts were breached in February. But few were clamoring for the popular service to introduce two-factor authentication until last week. That changed quickly, compliments of the Associated Press. The venerable news organization lost control over its Twitter account briefly, which got 0wned by a group calling itself the Syrian Electronic Army. The attackers only got as far as posting one bogus tweet, but that proved damaging enough. Claiming that President Obama was wounded in an attack on the White House, it triggered a brief market dip before everyone else realized the story was false.
It did not take long before the Monday-morning quarterbacks started speculating. Bloomberg criticized Twitter for waiting until the crisis to roll-out two-factor authentication, implying that it could have saved AP. (Because other companies have been deploying security features preemptively for no reason? Perhaps the parent company will reconsider the wisdom of a recent decision to add Twitter feeds into their popular data feed for finance professionals.) Meanwhile SC Magazine joined a chorus of sceptics in taking the glib view that two-factor authentication would have made no difference.
Which is it? As usual, the devil is in the details and depends . There are different ways to design two-factor authentication, and whether it can resist phishing depends critically on that. We can look at two points along the spectrum to see how they compare:
First one is what might be called “consumer-grade” two-factor authentication. This is what major cloud services typically offer end-users, balancing security against usability. The second-factor is a one-time passcode (OTP) delivered by SMS or generated using a mobile application. This design is indeed vulnerable to phishing, once the notion of phishing itself is slightly generalized. Obviously existing wave of attacks that only collect passwords will not succeed. But the miscreants are quick to adopt. Soon they will mimic the new login experience and also ask users for to type in the second factor. There is no reason to believe that the same users fooled into typing in their password into the fraudulent web page will stop short of doing the same with OTPs.
Fundamental problem is a weakness OTP shares with passwords: it puts the burden on end users to know they are authenticating to the “correct” website. If the address bar reads paypal.com that is good; but paypa1.com– with the digit 1 replacing the lower-case letter L to trick the unwary– that is bad. If that sounds like too much to ask for users, no wonder that combatting phishing has become a game of whack-a-mole where the measure of success is how quickly phishing sites are taken down once discovered. (But not before having claimed a few victims.)
That said, this type of second-factor still raises the bar for attackers. Because OTP codes are only valid for a short time period, the attacker is forced to “cash-in” stolen credentials right away by logging in with them. In other words the attack must be carried out in real-time. It is not possible to save the credentials, then come back and use them at a later point in time. In principle this also rules out a secondary market in resale of credentials, breaking the commercial model around account hijacking. It is no longer possible for Alice to phish for credentials, than later put these up for sale to Bob who specializes in pilfering personal data. Instead Alice herself has to do the plundering as well or at least collaborate with Bob at the time of attack, limiting her options downstream.
There is another way OTP may help, depending on the authentication policy: damage control. Typically the security policy requires user to re-authenticate periodically, for example every 24 hours. Even users who do not log out of their browser session will be asked to enter their credentials again after that time elapses. If such checkpoints require a fresh OTP, the attacker will be out of luck. After all it is one thing to get lucky and successfully trick the victim once; it is another to rely on repeating that feat every day.** Counter-point is that even access limited in time can be very damaging: one-full day is plenty of time to download all email and rifle through private documents.
Of course in reality, there are many ways for phishers to persist access after capturing both credentials. For example the system may have an option for “remember me” such that no additional OTPs are required when accessing the victim account from that machine. Similarly many large services incorporate deliberate “features” that become back-doors in the hands of an attacker. Application passwords are one such example as described in previous post on MSFT 2-factor authentication, as are oauth permission grants.
So far we discussed the failures of one particular 2-factor authentication design to resist phishing. In part II we will look at a different approach that is indeed resistant to phishing– and already used widely in enterprise/government settings.
** TOTP fares better compared to HOTP in this regard– with HOTP, attacker can collect additional codes in the sequence by pretending that the login did not succeed. Since TOTP codes are time-based, there is no way to phish for tomorrow’s valid codes today.