Anywhere Computing Makes 2FA Insecure On iOS and Android (thestack.com)

An anonymous reader writes: Academics from the VU University Amsterdam have identified a new class of vulnerabilities to two-factor authentication, commonly used to protect transactions involving financial and private information. The vulnerability leaves users of both Android and Apple mobile devices open to the theft of personal information by hackers. The researchers note the text (PDF). While anywhere computing is generally considered to be a good thing, the research claims that integration across multiple platforms essentially removes the gap between those platforms, and it is that gap that is required to make two-factor authentication secure. Without a gap between devices, a common hack called the man-in-the-browser attack can be elevated to intercept the one-time password generated for two-factor authentication, thereby rendering two-factor authentication useless.

Comments

Re:This isn't new..

[dgatwood]

Implementing a 'secure' token in software on an internet connected computer that also runs god knows what else has always been a shoddy idea; popular purely because it's cheaper than dedicated hardware; and possibly not quite as awful as your average password. It's never been, or even pretended to be, an actually trustworthy approach.

Exactly. And many of us have been saying that for years. The unfortunate problem is that many people see these sorts of technologies, and think to themselves, "This makes me secure", whereas in practice, the security benefit of any software-based second factor is zero if somebody has successfully 0wn3d your hardware. With that said, this statement doesn't go far enough. In practice, the security benefit of any second factor is zero if either communication endpoint is insecure, regardless of what the second factor is, and regardless of how many factors are involved.

Suppose I'm an attacker. If I can compromise your browser, I can show a fake error page. Therefore, if I want to do a transaction on your account, I can just wait for you to perform one, use your OTP to perform some nefarious action, then issue an error page, forcing you to enter a new OTP, then let the user perform the action again and allow the action to go through. Even better, I could perform the user action first, show an error page to trick the user into providing a new OTP, and then perform the nefarious action second. That way, I can show the legitimate response page at the end, as though the nefarious action hadn't happened, hiding the fact that I just transferred your entire account balance to an account in Switzerland or whatever. A sufficiently sophisticated attacker could actually fake all of the response screens sufficiently to mask their actions until days or weeks later, when your bank sends you a snail-mail letter telling you that you're bouncing checks.

That's why the first rule of computer security, IMO, should be, "If you can't trust both endpoints, you can't trust the data."

The takeaway for anyone who wants to be more secure is this: Always use your landline phone as your second factor, and make sure that it is POTS-based and not a VoIP home phone. In some cases a POTS line can be trunked in a way that could make it possible to redirect calls somewhere else through software-based attacks, so for a truly skilled attacker, even that isn't 100% safe, but it is orders of magnitude safer than a cell phone.

The takeaway for banks and other institutions is that Internet-connected devices make poor second factors, and they should really collaborate to come up with a common platform for second-factor authentication using shared hardware tokens (e.g. OATH with OTPs) and require their customers to use them. Ideally, they should do so in a way that the customer can use a single second factor for all their accounts at various banks, relying on the passwords to ensure that someone who steals the fob won't gain access to all of the user's accounts. And ideally, they should come up with a way to provide (with some reasonable degree of certainty) a hash check on the password to ensure that the user doesn't use the same password on multiple sites. This could be a good browser feature.

The takeway for OS designers is pretty extensive; I'd recommend that anybody involved in any sort of operating-system security read the original white paper, because it would take too long to summarize the chain of attacks involved.