Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

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.)
This discussion has been archived. No new comments can be posted.

Phishers Defeat Citibank's 2-Factor Authentication

Comments Filter:
  • Re:No Good (Score:5, Informative)

    by maxwell demon ( 590494 ) on Tuesday July 11, 2006 @06:02AM (#15696622) Journal
    I don't think he meant "encrypted" to be "cryptic looking". Instead I think he was thinking of actal encryption, where the email appears to you in plaintext if your email program supports encryption (and you have the proper key, of course). Especially if you have to get a physical token anyway, it should be no problem to store a personal key on it as well.
  • by maxwell demon ( 590494 ) on Tuesday July 11, 2006 @06:14AM (#15696647) Journal
    Well, probably they open bank accounts under false identities, and close them again immediatly after they got the money. For the next phishing attack they just can open another account under another false identity at another bank. All they need to be good in is in faking (or maybe stealing) identities (and of course in actual phishing). If that bank account is emptied and closed quick enough (i.e. before you note that someone took money from yor account), there's no way to lock it, and probably hardly a chance to find the person who had opened it.
  • by Anonymous Coward on Tuesday July 11, 2006 @06:19AM (#15696664)
    Customer number + pin, then new code for every transaction. Been using it for years. Can't even login to the Sampo web-bank without these 3 things. They may grab my account number and pincode as much as they want cause, they're doing shit with those codes without my every-time-changing code. Welcome to Finland.

  • Re:carding (Score:1, Informative)

    by Anonymous Coward on Tuesday July 11, 2006 @06:35AM (#15696696)
    What you are referring to is called a One time pad" [] which this token effectivly provides, this is still vulnerable to man in the middle attacks, though
  • Re:Bank Security (Score:2, Informative)

    by OP_Boot ( 714046 ) on Tuesday July 11, 2006 @07:11AM (#15696786)
    Out of all of your suggestions, only one - Signing transactions - will defeat a man-in-the-middle attack such as is described by the article.
  • by v1 ( 525388 ) on Tuesday July 11, 2006 @07:39AM (#15696856) Homepage Journal
    SSH is specifically designed to prevent MITMA. If I try to ssh to a system that I have recently swapped hardware on and still have the same hard drive, ssh flips out and warns me of a possible MITMA due to the MAC address of the destination having changed. (it displays a short warning saying "someone may be doing something nasty!") In fact, it won't even let me ignore the error, I have go go into the known_hosts file and remove the previous fingerprint before it will let me ssh into that system again. This problem never occurs unless I have changed the machine I am ssh'ing into, so there are no false positives to get accustomed to.

    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.
  • by azknom ( 226212 ) on Tuesday July 11, 2006 @07:48AM (#15696888)
    Add to this that you must authenticate every new destination and the phishers will have a really difficult time to get any money. They need to have my authentication device to add their own account and then add a transfer to the ones I do myself without me knowing. I cant see this happening. Sure thay can see what I have on my account by sitting in the middle and tehy can see all I do but they can not change what I do without my authentication device. I have used this since 1997 here in Sweden and would never trust a simple password to do my banking.
  • by Octorian ( 14086 ) on Tuesday July 11, 2006 @07:50AM (#15696904) Homepage
    Client-side certificates work just fine in non-MS browsers and E-Mail clients. The problem, as mentioned in other posts, is in certificate distribution. All these other browsers do support installing client certificates off of websites, but often you'll find a site that insists on some weird ActiveX crap to handle certificate installation. Where I work, this is especially frustrating, as we have a lot of Mac users (including myself). So, we find a Windows machine, go through the process, export the certificates/keys, sneakernet them to our systems, and install them.
  • by accident ( 575230 ) on Tuesday July 11, 2006 @08:10AM (#15696994)
    This is whats possible when both tokens are "passive" - that is they play no part in the negotiation and are one way (even if valid for a short time).

    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.

  • by Anonymous Coward on Tuesday July 11, 2006 @08:12AM (#15697007)
    SSH is specifically designed to prevent MITMA. If I try to ssh to a system that I have recently swapped hardware on and still have the same hard drive, ssh flips out and warns me of a possible MITMA due to the MAC address of the destination having changed.


    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 /etc. And moving the hard drive to a different machine does NOT change the host key. Re-installing does, however.
  • by Leebert ( 1694 ) on Tuesday July 11, 2006 @08:20AM (#15697042)
    ssh flips out and warns me of a possible MITMA due to the MAC address of the destination having changed.

    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.

    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.

    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)

    by J0nne ( 924579 ) on Tuesday July 11, 2006 @10:09AM (#15697662)
    My bank requires you to install some java software + some keys in your C:\ or /home/ before you can use online banking (and it's protected by a password).

    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.
  • by Anonymous Coward on Tuesday July 11, 2006 @10:38AM (#15697913)
    is use pictures. You login to the site using a username which takes you to another page. They then present you with a picture you chose when you opened up the account, you can even upload a picture I believe. If you recgonize the picture you chose then you know you are on the correct site and can put in your password safely. If you go to a malicious site they are not going to be able to present the correct picture. There is no way a man in the middle attack can succeed unless the user just forgets to check for the picture and puts in their username/password anyway. It is the first thing I look for though, yep there is the picture I know I am on a Bank of America server.

    - Jeremy

"Our vision is to speed up time, eventually eliminating it." -- Alex Schure