A short rebuttal of Two-factor authentication is false sense of security
For starters, what makes the password so broken is the fact that the shared secret (the password) is stored right where it’s subject to attack (the website).
That's not what makes the password so broken so long as the web service provider is doing everything right – storing the password hash instead of the raw password, using bcrypt with a significant work factor to generate that hash, and using a per-password salt.
I also (weakly) disagree that the website is the most likely attack vector, assuming he means an attack that grants access to the database or application server. The language is ambiguous, so I'll give him some benefit of the doubt and assume he's talking about XSS exploitations, which can compromise a website without requiring direct server access.
What an attacker really wants to do is intercept the password as it's going through the wire in cleartext – as close to the frontend as possible. This is why it's important for sites to use SSL whenever they deal with sensitive user input. SSL guarantees an encrypted connection with the remote server so anyone eavesdropping on the connection will only see a bunch of encrypted data rather than your passwords and credit card numbers flying around.
In most two-factor authentication deployments, a user will be asked to share something else with a site (such as texted code), which will then be stored, again, where it’s subject to attack. Instead of fortifying the security, we’ve actually increased the amount of user information that’s shared.
This is a misunderstanding of how the single-use codes work. They are never supposed to be stored – they are computed and compared and thrown away. The whole point is that they are ephemeral. I would hesitate to call them "user information". A password is "user information" as it's a long-term secret chosen by the user. A single-use code generated by a two-factor auth device is not controlled by the user at all and the codes only exist for a short period of time – typically less than a minute.
The short life of the code is the whole point of two-factor. Let's say we have an attacker who is sniffing the connections of twenty users and sending them to server, where he logs in once a day to check out what he's found (assume the web service provider is Doing It Wrong and serving their login page over HTTP instead of HTTPS, or that there is some XSS vulnerability). With one-factor (password-only), the window for attack stays open as long as the password doesn't change. For most users, this is indefinite.
With two-factor authentication, however, the window for attack is non-existent. Even though the attacker has the password and the single-use code that was used to login, she will need a new single-use code to access the user's account. Even in implementations that don't immediately invalidate the code upon use, the attacker still only has seconds to gain access, rather than an indefinite amount of time.
Deploying two-factor authentication means issuing tokens or embedding cryptographic keys in user devices, and both of those approaches require user participation. Experience to date has shown that, in cases where two-factor authentication is provided as an option, most users won’t use it — the security is not worth the pain of the experience. Consumer usage rates are in the low single digits in opt-in models.
The whole "Usability" section contains nothing about how two-factor is a false sense of security, so I will ignore it.
Most two-factor authentication technologies generate a one-time code for users to then provide to authenticate their identity. But this common implementation is not immune to today’s threats or emerging ones. Cyber thieves use Trojan-horse malware, for example, that tricks a person into approving an attacker’s transaction without knowing it. Malware on users’ phones that intercepts SMS messages and sends them to an attacker is also becoming more common.
There are a few things to pick apart here. With a password-only service an attacker can passively collect passwords and use them at will, as mentioned above. With a two-factor service, the attack requires significantly more precision. When a user gets an SMS with the single-use code, all that is contained in the message is the code. So an attacker will have to know which "incoming" phone numbers map to which service, which is arguably not difficult. The harder part is knowing which "recipient" phone numbers map to which user on that service.
To sum it up, security is not binary. Security is about reducing the efficacy of attack vectors. Two-factor authentication does an excellent job of mitigating some pretty serious attacks.
Jim Fenton is the chief security officer for OneID and is responsible for security design of the OneID identity system as well as oversight of the company’s corporate information security.
This guy is a chief security officer. I have no doubt in my mind that he's well aware of everything I'm saying here, however he has a business incentive to increase fear around two-factor since his company is selling a competing solution.
Thanks for taking the time to write this. If you'd like to discuss it further, I'm jimfenton on Github and @jimfenton on Twitter.