Two-Factor Authentication = F
Our well respected peer Bruce Schneier as an interesting post about an article on the failure of two factor authentication.
According to the article, phishers are using some new techniques to bypass the two factor authentication that some banks are using for account access. The phishers are spoofing the bank sites elsewhere (as ususal), and are including the fields for the token entry for login. When the unsuspecting user enters the token into the ohisher's site, the site then contacts the real bank and presents the credentials as provided bu the user - so if the token is wron, they can modify the spoofed error page until they get a correct one.
Pretty slick.
The article refers to this as a "man in the middle attack", and while I don't agree with that description (in the traditional sense), I think that it sums it up for the end user.
Now, I certainly don't think that two factor authentication is dead, but at least take a good look at how the whole system works. And now it appears that we need to account for these type of issues when designing two facto authentication systems.
- Larry
Failure of Two-Factor Authentication
Here's a report of phishers defeating two-factor authentication using a man-in-the-middle attack.
The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit -- a tactic used by some security-savvy people -- you might be fooled. That's because this site acts as the "man in the middle" -- it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real.
I predicted this last year.
Comments
Larry - Interesting, and I agree that it's not quite a MITM attack. I read through many of the comments on Bruce's blog - doesn't seem that anyone is pointing a finger about application-level (HTTP) firewalling, and the problem of the web application itself being to trusting. This sort of problem seems exactly like the sort of issue that Sentryware's HIVE product is built to solve (not the only solution, but an example).
Thoughts?
BTW - stumbled onto your blog from the SC Magazine mention of you and your working world. Nice press.
Posted by: Dan Keldsen | July 13, 2006 05:29 PM
What really impresses me is that almost everybody that is suggesting solutions for this are thinking about the problem as "how the original site can identify that the request is not coming directly from the real user?". THIS IS NOT THE RIGHT APPROACH!
Last year I presented a Proof of Concept code in a security conference. That code was created as a Browser Helper Object, but the main concept can be done by other means. The code was created to target a specific web application, an Internet Banking that uses two factor authentication. It doesn't try to steal authentication credentials, but it uses a valid established and authenticated session . In my PoC, whenever the user executes a wire-transfer transaction, the destination account number is replaced by another account. The confirmation sent by the server is also modified to show the original destination account. The user can't notice anything wrong in his experience, but his money has just been sent to another destination.
Why bother about stealing credentials when you can use the session that has been established by the user to perform what you need to do? If you chose to not steal credentials you have the additional benefit of not having to find a way to send them to you. No need to disable personal firewalls, NAT issues, etc.
The real problem (technically speaking) is the user actions (using bogus websites) and his environment (backdoors, trojans, DNS poisoning). Two-factor authentication will not solve any of them.
Posted by: Augusto Paes de Barros | July 13, 2006 06:47 PM