Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Phishers Defeat Citibank's 2-Factor Authentication 233

Posted by timothy
from the time-is-of-the-essence dept.
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:
  • Good. (Score:5, Interesting)

    by bytesex (112972) on Tuesday July 11, 2006 @04:32AM (#15696543) Homepage
    My bank has had this for ages. How's about protecting you from the man in the middle attack by a little extra procedure, though ? Immediately after you've done the transactions through the web and you log out, the bank sends you an encrypted email with all your transactions in it. Those emails can be parseable for your own financial package as well. And it should give you some time to cancel all the transactions that are bogus. There can be no forgery involved, since the bank _always_ sends those mails. Just an idea, I know there's no cure for utter stupidity.
  • Rabobank security (Score:4, Interesting)

    by mwvdlee (775178) on Tuesday July 11, 2006 @04:33AM (#15696546) Homepage
    My bank (Rabobank, netherlands) uses a key-generating hardware device, based on account, PIN number, optional numbers generated by the site (which are to be entered into the keygen) and an internal clock. With sending any transfer, the site requires a new key to be generated. If the amount to be transferred is sufficiently large, one of the numbers used to generated the key is the exact amount, thus requiring the user to validate the amount as well.

    Phishers may be able to coordinate up to the point of this validation, but if one suddenly had to enter an additional verification number of, e.g. "2000.00" (minus the decimal point), it'd be very hard to use phishing for large amounts of money.

    Then again, I also have other accounts at two other banks, both of which require only a one-time, 5/6-digit, non-changing, numeric password.
  • by Sawopox (18730) on Tuesday July 11, 2006 @04:59AM (#15696614) Homepage Journal
    The solution to 99.99% of the problems we face today is education. But, as they say, "Ignorance is bliss." Some people today simply DO NOT CARE to put forth the effor to make any kind of change in their life. So long as the welfare check comes every month, and American Gladiators is on 24/7 re-runs, they're happy. What is worse, is this "So, what?" attitude we see in adults is being passed onto their kids. I teach middle-school, and sometimes I just want to scream, "WAKE THE FUCK UP AND OPEN YOUR GODDAMN EYES!" at the top of my lungs.

  • Re:Good. (Score:3, Interesting)

    by porlw (169848) on Tuesday July 11, 2006 @05:00AM (#15696618)
    My bank sends me an SMS with a one-time password every time I do a transaction online. You have to type in the password on the web page to confirm the transaction.
  • Nothing surprising (Score:5, Interesting)

    by arivanov (12034) on Tuesday July 11, 2006 @05:04AM (#15696630) Homepage
    Nearly all US and UK Internet banking systems are susceptible to this.

    There is an easy fix for this as well - client side certificates. I have an account with a bank in an ex-eastern European country and they use it. Many scandinavian banks use that as well (with the certificate on a token or a smartcard).

    In order to authenticate the SSL handshake has to use both client side and server side certificates. After that the actual user id has to match the certificate one. A man in the middle cannot break through that because it will not have the private key from the user machine. From there on even if it can fake the bank interface to the user it cannot fake the user towards the bank. Game, set and match.

    The only reason for US and UK banks not to use it is outright incompetence. I remember trying to explain the concept of client side SSL certificates to one of the cretins who have implemented a well known UK bank Internet banking security subsystem. He could not grasp the concept. By the way - he now works in the "risk" (that is the way they like calling this now) department of another well known UK bank.
  • Re:Rabobank security (Score:3, Interesting)

    by strider44 (650833) on Tuesday July 11, 2006 @05:12AM (#15696643)
    I'd think the numbers would be pretty much hack-proof if one of the factors that you needed to put in the token or hardware device was the target bank account. This would obviously make banking slightly less convenient as you'd have to enter a new number in every time you transfer but it would save a lot of touble and be impervious to this type of attack mentioned in TFA.
  • Re:Rabobank security (Score:4, Interesting)

    by dr_d_19 (206418) on Tuesday July 11, 2006 @05:17AM (#15696655)
    Phishers may be able to coordinate up to the point of this validation, but if one suddenly had to enter an additional verification number of, e.g. "2000.00" (minus the decimal point), it'd be very hard to use phishing for large amounts of money.

    No it will not.

    This is an example of how the man in the middle attack would occur on any Swedish bank

    Hello, welcome to CitiBank, please insert your account number and the response to the following challenge: 8022 8429
    - "Uhm, ok" (login via man in the middle)

    There was a problem, please try again with the following challenge: 2842 2020
    - "Oh, my bad" (add phising account to users account allow list)

    You will need one more challenge/response pair however, which you can get using:

      - A third login problem
      - Any action performed by the user that would require the response/challenge usually
      - Information about "heightened security" and the need to re-verify the identity.
      - Information about an e-visa/new savings account/free stocks or anything that would potentially require a challenge

    So this is very possible.

    This can be solved using client side certificates tho'.
  • Re:Good. (Score:5, Interesting)

    by stunt_penguin (906223) on Tuesday July 11, 2006 @05:33AM (#15696691)
    You're right aboout there being no cure for stupidity- however a transaction recipt after every transaction might lead to people being phished using 'ZOMG SOMEONE JUST WITHDREW $1000 FROM YOUR ACCOUNT, CLICK HERE TO ENTER LOGIN AND CANCEL!!1one1!eleventy' tactics.

    There is, it seems, no winning.
  • by FireFury03 (653718) <slashdot@nexusGI ... minus herbivore> on Tuesday July 11, 2006 @05:39AM (#15696706) Homepage
    But in this case simple and common SSL certificate verification would work to stop such a man-in-the-middle attack.

    SSL (and other such certification systems) present a trust problem:

    When I connect to Alice, she presents a certificate which is signed by Bob. This tells me that Bob has verified that Alice is who she says she is. All very good you might think... except why the hell should I trust Bob? Maybe "Alice" is really Charlie pretending to be Alice and Bob signed the certificate because Charlie paid him a whole heap of cash. Or maybe Bob just didn't actually bother to check before signing the certificate. Either way, I don't know Bob and so he hasn't earnt my trust.

    In this case, Bob is someone like Verisign - a large corporation who has been paid a reasonably large amount of money by Alice. If there's one thing I've learnt it's that most large corporations are fundamentally untrustworthy, especially when they're receiving bundles of cash from someone.

    This kind of trust problem is not easilly solvable (if it's actually solvable at all). One potential way to do things is have a social network - each person signs the certificates of each of their friends and assigns a "trust score" showing how strong their trust relationship is. When I want to see how trustworthy Alice is, I traverse the network if signatures between me and Alice and can calculate the end "trustworthyness" from the scores of all the interconnections in the network. The problem here is that there usually aren't that many hops between any 2 people in the network - I might trust Bob and Bob might trust Alice, even though *I* don't trust Alice.
  • by arivanov (12034) on Tuesday July 11, 2006 @05:58AM (#15696760) Homepage
    Strange.

    No particular reason for client certificates to fail to work once loaded in a non-MS client. I got the east-EU bank mentioned in my original post working correctly with konq and mozilla.

    Now, smart cards are a different matter. Some of them are not supported under *nix and MacOS. If the card is supported you should still be in the game.

    Similarly, requesting certificates may be a problem. Mozilla has some troubles with handling the certificate-request/certificate import sequence. So does konqueror. It also cannot load a certificate with the same Subject as an existing certificates into the cert store. This makes requesting certificates via an interface which in turn requires a certificate to authenticate a real pain.

    In either case it can be made to work. May be a bit painfull and I understand banks which refuse to provide support for anything but IE for this purpose (f.e. because of the aforementioned mozilla cert request sillies). As long as they do not outright deny you the possibility to use something else by using IE only features in the UI I am OK with that. I can sit down once a year on a windows machine to renew the certificate while swearing at Mozilla people for indexing their store based on Subject, not subject+serialNo.

    Overall it can be made to work and it solves 99% of all phishing outright. IMO it is criminal for the banks not to use that. No rocket science involved.

  • by ndg123 (801212) on Tuesday July 11, 2006 @06:01AM (#15696763)
    Actually quite a few people use this for personal transfers in the UK. For example if I go for a weekend trip with some old college friends who now live in different parts of the country, I may book all the flights or hotel rooms. Setting up a transfer direct to their personal accounts is quite useful and quick, compared to cash or cheques. My online banking used to take a couple of days to set up these arrangements, and now its immediate. I think this is rather dangerous.
  • Re:No Good (Score:3, Interesting)

    by Tony Hoyle (11698) <tmh@nodomain.org> on Tuesday July 11, 2006 @07:04AM (#15696967) Homepage
    Users know nothing about encryption... it's too easy to spoof.

    eg. There's a virus going around that reads "This is an encryted email from AOL.. click on the attachment to read it".

    Telling users that encryption is somehow better is just going to leave them open to that kind of attack.
  • Re:carding (Score:2, Interesting)

    by WedgeTalon (823522) on Tuesday July 11, 2006 @07:10AM (#15696995)
    A lot of people, like you, are suggesting sophisticated technological solutions (which won't really work IRL). The REAL problem isn't the bank's security - it's the user's gullibility. My bank simply uses a username/password style login. It works fine. The only one with problems are those who believe evrything they get in their inbox.
  • by fdiskne1 (219834) on Tuesday July 11, 2006 @07:12AM (#15697008)

    I know this won't fix all problems with phishing emails, but it should fix one factor of it. Could those who contribute their programming skills to Firefox make it so the actual domain of the site you are at is highlighted? This means that if you are at a site

    http://citibusinessonline.da.us.citibank.com.tufel -club.ru/sahdlhasal

    Firefox would display it as:

    http://citibusinessonline.da.us.citibank.com. tufel-club.ru /sahdlhasal

    I know some victims refuse to think about it at all and refuse to even look at the URL but this would give them one more tool to use to possibly see it is a scam.

  • by Distan (122159) on Tuesday July 11, 2006 @09:38AM (#15697909)
    A primary reason for the difference between US security standards and European security standards is the compute environment, and hence, the assumption of trust given to the terminal.

    In the US, most users are accessing their accounts from their work or home computers. Although keyloggers may be present on these machines, it isn't very common yet. In northern europe, the use of internet terminals in cafes or kiosks is much more common. On these machines, it is likely that keyloggers will be present, so it is conservative to assume that everything the user does will be logged someone.

    This assumption (everything the user does is logged) drives the need to require access to some thing (PIN grid, token generator, etc) that is needed in addition to the normal username and password. The higher level of justified paranoia drives a higher perception of security requirements.

    One tremendous downside to this: loss of one of the best features of online banking - ease of use and portability. I personally have about ten online accounts with different banks, and I use all those accounts frequently. Everything I need to know to manage my personaly finances is carried in my head, and I can access my accounts from any computer anywhere in the world with nothing more than the knowledge I possess. Having to carry any sort of physical object to access my accounts would be a tremendous loss, one that would probably drive me to seek another bank, or a bank in another country, to avoid.
  • Postbank (Score:3, Interesting)

    by Captain_Chaos (103843) on Tuesday July 11, 2006 @11:27AM (#15698881)
    I like how the Postbank does it here in the Netherlands. For every transaction (which may include multiple transfers) they SMS you a random number which you have to enter in the site to validate the transaction. They send the SMS to a phone which they previously determined belongs to you (you don't enter the number on the spot or something like that). A phisher might hack your Postbank account, but they won't be able to impersonate you since the security number (and the total amount of money involved in the transaction) is sent to your cell phone which they can't get at (and which alerts you to the fact that your account has been hacked).

    In the past (actually it's still possible for people who don't have a cell phone or don't want to use this system) the number wasn't sent as an SMS, but was on a long list of numbers they would mail you (the list was printed and sealed by a machine, no humans would see it before you). This was a nuisance because I kept losing the list and it was a hassle to use, but this new system is quite convenient in my opinion. I always have my cell phone with me, so I can do my banking from any location.
  • by kurzweilfreak (829276) <kurzweilfreak AT gmail DOT com> on Tuesday July 11, 2006 @12:19PM (#15699272) Journal
    What about online bill paying? If you were a phisher you could brake into someone's account and set yourself up as a vendor to be paid, get the check, cash it, and then delete yourself and your info out of the online bill payment section. Yeah, it leaves a pretty bad paper trail, but it's still doable.

    Something similiar happened to the company I work for a few years back, except it was done by an inside employee from the bank who found a flaw in their online system. All current accounts (without informing any of the account holders) the bank had were given a username and the same default password when their online access system was set up. By getting a list of all the usernames, it was no problem for them to log in, set themselves up as vendors to be paid, and then have a check mailed to them from the bank automatically. They were caught when trying to cash the check and a suspicious bank clerk called for confirmation before cashing the check.

If entropy is increasing, where is it coming from?

Working...