Phishers Defeat Citibank's 2-Factor Authentication 233
An anonymous reader writes "Crypto experts and U.S. Government regulations (FFIEC) have been pushing the need for financial Web sites to move beyond mere passwords and implement so-called "two-factor authentication" — the second factor being something the user has in their physical possession like a token — as the answer to protecting customers from phishing attacks that use phony e-mails and bogus Web sites to trick users into forking over their personal and financial data. According to a Washington Post Blog, 'SecurityFix,' phishers have now started phishing for the two-factor token ID from the user as well. The most interesting part is that these tokens only give you one minute to log in to the bank until that key will expire. The phishers employ a man-in-the-middle attack against the victim and Citibank to log in via php and conduct money transfers immediately when logged in." (An update to the blog entry notes that the phishing site mentioned has since been shut down.)
Re:No Good (Score:5, Informative)
Re:Man in the middle will always work (Score:3, Informative)
what is your major malfunction? (Score:2, Informative)
-m10
Re:carding (Score:1, Informative)
Re:Bank Security (Score:2, Informative)
Re:Man in the middle will always work (Score:1, Informative)
Although this prevents MITMA, it does not necessarily prevent phishing by default because the phisher could somehow trick me into ssh'ing to the wrong address, by hacking a DNS for example. However there is one further security feature of SSH. When you are ssh'ing into a system that you have never connected to before, it displays a warning and asks if you want to add the new host to your list of known hosts. Since you should never get this except the very first time you connect, if you see this warning when connecting to someplace you visit regularly, you know something is wrong.
I suppose the best defense to phishing instead of 2 part authentication, would be to send the users the program to access their content. Imagine the bank writing an ssh-enabled client with the fingerprint of their server hard coded into it, where it remembers your account information as well so you don't get used to typing in your bank password whenever asked for it. No link to click, just "run the bank program" to access your account. Even a dns compromise would not impact this. The only issue I can see with this method is storing the acccount information in a way that cannot be extracted by spyware AND not in a way that can be used in its encrypted form. (such as hashed)
The big problem with phishing here is simply that the user is too used to being asked for their account information, and as long as the phisher doesn't deviate too much from the norm the user will just go zombie and type it in. This information needs to be something you enter once, and if it ever asks you again there is a problem.
But in the end, profound user stupidity trumps all. That will never change.
Re:what is your major malfunction? (Score:2, Informative)
Re:Nothing surprising (Score:3, Informative)
Both tokens were passive (Score:2, Informative)
What is needed is for one of the tokens to be "active" in the negotiation. Anything that can perform a unique challenge-response will fix the MITM attack.
As others have stated, client side ssl certificates, hardware tokens with key-pads, smart cards, trusted-computing would suffice.
Re:Man in the middle will always work (Score:2, Informative)
WRONG.
SSH does NOT care about the MAC address. The MAC address is only valid on a LAN. Every time a packet passes a router, the MAC address gets replaced, so it would be completely useless for any kind of authentication. Plus, changing the MAC address can be done in software easily. As I tend to tell people who do wireless networks: Forget about MAC filtering, cracking it takes less time (seconds) than activating it.
What SSH is complaining about is the host key. It has nothing to do with the hardware, but is located in a file in
Re:Man in the middle will always work (Score:3, Informative)
No, it doesn't. You can change hardware (and even platforms) all day to your heart's content. What you CAN'T do is change the public key. If you, for example, uninstall ssh, and the uninstall removes the keys, and then you re-install ssh and regenerate the keys, you will get this message.
No, that wouldn't work. ssh stores a fingerprint for the server's public key. The fingerprint is associated with both the host's DNS name and its IP. If you were to poison DNS and cause me to connect to a different hostile machine with the "same" forged hostname, the public key of that hostile machine would differ. ssh would completely wig out and say that a man in the middle attack may be occurring.
There's plenty of ways around 2-factor authentication within ssh, but this isn't it.
My bank (Score:2, Informative)
It's a bit complicated to set up (especially in Linux, although the instructions were good enough to figure it out), but I don't see how phishing would work with this system. An attacker would have to trick the user into sending the 3 files with keys + entering his password.
You could get what you need easily with a trojan and keylogger, ofcourse (well, good luck tricking me into installing a trojan on Ubuntu), but sending e-mails with 'please enter your password' won't do a lot for a phisher. Besides, I don't even think my bank has my e-mail address, and I would find it very suspicious if I ever received an e-mail from them.
Phishing works because some banks apparently set up their online banking systems in the same way as slashdot, with just an username and password. That's fine for unimportant stuff, but when handling money, a login/password just won't cut it.
One thing Bank of America does..... (Score:1, Informative)
- Jeremy