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 @05: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.
    • 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.
      I regularly receive "encrypted emails", all apparantly malware. Unfortunately your idea will lead to more people clicking on "encrypted emails" and getting infected, rather then immediately binning them, thus replacing one problem by another.
      • 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.
        • Re:No Good (Score:3, Interesting)

          by Tony Hoyle (11698)
          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:Good. (Score:3, Interesting)

      by porlw (169848)
      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.
      • So you just pass the password through to the "Man In The Middle"!

        The MiM is the hardest security problem by far there are no easy answers.

        It would make more sense for your bank to do it the other way around --
        display a password on the screen which you send them via SMS, this provides
        two checks -- the password and your mobile number.

        Tough if you lose your mobile though -- you lose access to your account as well!
        • Re:Good. (Score:2, Insightful)

          by porlw (169848)
          Note quite.

          1. The SMS only happens if you actually try to do a transaction.
          2. The SMS also supplies destination account and amount.

          So MIM would only work iff they intercepted an attempt by me to make a payment, and I didn't check the details in the SMS. If I get a transfer SMS out of the blue then I know something's up.

          If I lose my mobile then I do what our stone-age ancestors did, and actually go to the physical bank building and fill out a transfer request.

          If I make regular payments to a particular accoun
        • > The MiM is the hardest security problem by far there are no easy answers.

          Umm, SSL was designed to solve this problem. When you visit your online bank, make sure the cert is valid and that the URL matches the one on your printed bankbook or credit card.

          Pretty simple.

          (People being too dumb/lazy to check, though, is the hard problem. Fortunately this is evolution at work.)
        • My bank does the same thing as the GP's, and in the even that i don't own a mobile, I can still get the Transaction Authorisation Code from the bank's phone banking facility or by getting a one time use code from the 24 hr ATM. After all, the reason this works when stopping phishing is because there is a hurdle not related to the internet that needs to be over come, so phone or walking to an ATM works just as well.

          Anyway, what are the odds that you are of the demographic that uses phone banking, but doesn't
          • Very out of form to reply to myself, but the "phone banking" in the 2nd last line ought to read "internet banking" ...
    • Re:Good. (Score:5, Interesting)

      by stunt_penguin (906223) on Tuesday July 11, 2006 @06: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.
      • Re:Good. (Score:3, Insightful)

        by stunt_penguin (906223)
        ^ sorry, your method of sending all (or all recent) transaction info as a mark of authenticity in the email would probably help to eleminate that type of attack since the phishers would have no way of providing this info.

        Having said that, with current methods, maybe a 'someone just transferred $1000 [such an arbitrary number, don't you think?], please login in the next 24 hours to cancel this transaction' might be an effective phishing technique, rather than the old 'we los your details, oops!' tactic; h
        • by wik (10258)
          If the phishers can login and access your bank account to withdraw money, why can't they also read the last few transactions from the webpage as well?
          • Sorry, I was on about the initial phishing email, where they usually ask you to confirm some details that they've supposedly lost.

            If a bank included your recent transaction details in all electronic correspondance as standard then that would be a very good sign of authenticity for banking emails. The absence of those details and the difficulty in obtaining them would make a user suspicious and make a phisher's task in creating a convincing email that included recent transacion informaton impossible.
      • by ajs (35943)
        Winning is easy. Don't deal with your bank online unless you type in the name directly or use a bookmark, and always double-check the spelling.

        The other way to go would be to have some very short domain name that everyone comes to recognize as a gateway (sort of a tinyurl for financial institutions), and have every bank interaction start with something like this:

        To containue, please visit, http://bankurl.com/citibank

        or the like. That way, the user knows that any site NOT asking them to do this is phishing,

        • Humm..... I wasn't so much on about winning a personal battle against these scams as keeping people in general from getting caught; getting people to do anything to protect themselves en-masse is difficult to say the least :(
    • How about this: buy some stuff, then (after receiving it or knowing it can't be returned) cancel the payments. Should work great on paid downloads & online stores, as well as services (e.g. taxi, car wash etc.).
      • I guess that in the parent idea, the bank will send the confirmation of payment or move the money only when you have approved, cancel the operation.

        Anyway, if you want to trick shops like this, this is already possible with a good old Credit Card. Call the credit card company say that you do not recognise some operation or that the vendor didn't do his part of the contract and you will be refunded immediatly.

        Disclaimer, don't try this at home, you could have some trouble with Justice after that.
    • Loggin is the usual user/password combo, nothing special but if you want to transfer money the final step is that they send a code to your mobile phone via a sms message. The code then has to be entered for the transaction to be processed.

      You can change your mobile phone easily enough, just change it in the settings but that also requires a sms message with a code. So as long as you got your phone you are safe.

      If you lose your phone you will have to disable your account and you will be send by mail a new

    • by Lumpy (12016)
      giving you a customer high security to your accounts is not in the interest of the bank. They do not make money off that therefore it will not be even addressed. Most banks still use a really cheezy login system, (some like 5th 3rd used to send your password in the open when you went to the account settings page. It displayed openly your password on the screen.)
    • I've seen another tactic at a UK bank to protect login: online customers are given a security password generated by the bank in addition to a regular password and "secret information" entry. The generated security password is never requested in full. Instead, several random characters from the password are requested at login; i.e., "What is the 3rd character of your security password? What is the 1st character of your security password? What is the 5th character of your security password?"

      If the user falls
    • Re:Good. (Score:2, Insightful)

      by SilverJets (131916)
      How's about protecting you from the man in the middle attack by a little extra procedure, though ?

      How about not clicking on every bloody URL in every e-mail you receive?

      No matter how good the security, it will always be defeated by the stupid users it is there to protect.
  • Rabobank security (Score:4, Interesting)

    by mwvdlee (775178) on Tuesday July 11, 2006 @05: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.
    • Re:Rabobank security (Score:3, Interesting)

      by strider44 (650833)
      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 @06: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'.

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

        This can be solved using client side certificates tho'.

        Not quite all. Eg Handelsbanken uses certificates instead and is thus safe from MITM attacks.
        • > Not quite all. Eg Handelsbanken uses certificates instead and is thus safe from MITM attacks.

          But your the certificate can be stolen, though. One bank used to use a certificate
          and a 4 digit PIN code for access, and only Windows was supported. Sure certificates
          are better than nothing, but they need to be augmented with something else to
          make them safer.
      • That problem would be easily solved by simply linking the site-generated validation codes to the action they are supposed to validate; you couldn't log in using the "allow" challenge. At best, a phisher could piggy-back on the actions of the user. If the target account numbers are used as validation codes (along with action validation codes ofcourse). The best a phisher could possibly do is change the amount... unless ofcourse, that amount is also used as a validation code.

        Now *surprise*, this is exactly wh
    • by Zemran (3101)
      That all sounds too complicated for me, I think I will just stay poor instead...
  • Are you surprised? (Score:3, Insightful)

    by Manip (656104) on Tuesday July 11, 2006 @05:33AM (#15696548)
    This isn't at all a shocker. The authentication problem is only one piece of a very complex puzzle. But in this case simple and common SSL certificate verification would work to stop such a man-in-the-middle attack.

    Further down the road though, this is why technology leaders need to standardise authentication tokens to include some kind of two way verification ... So when you enter your token into the browser, first the browser checks the web-site is the "owner" of that token and if it is not then it warns the user, after verification the browser then sends the token and the user is verified to the site.

    Something like this:
      mybankcom - 9 -

    The browser implements a "token box," when a post is attempted with said box the domain gets stripped of all special characters (up to the path) and then compared to the first part of the token. If they are case insensitively identical then the browser will submit the rest of the token (the pseudo random number) to the web-site.

    The token box would have to look unique and be very difficult to clone... Which might require it to jump out from the main content window, but that is a problem for browser UI developers and beyond the scope of the problem.
    • by FireFury03 (653718) <slashdot.nexusuk@org> on Tuesday July 11, 2006 @06: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 grrowl (953625) on Tuesday July 11, 2006 @05:35AM (#15696554) Homepage Journal
    The target authorities and security developers should be aiming for, in my opinion, is not the people who do the wrong-doing, but the users themselves. The major difference that phishing has from hacking or physical robbery is that the attack is forceful against either the bank's online front or the customer whereas phishing preys on not physical or technological weakness but on intellectual weakness: ignorant users are conned into giving up personal details, going to a particular site or running a program because they are unaware of the risks. In phishing cases there really should be a bigger push for educating customers through more than just 20-pixel-high signatures on electronic correspondance. There should be in-bank brochures, tv spots/advertisements (or at least addendums to current tv spots) and users should clearly know never to click a link in an email from anyone, especially if it's pertaining to a bank or paypal-like site or in a personal mail from someone unfamiliar. There's a reason many geeks have clean-as-whistle computers (I virus and spyware scan every now-and-then -- about every 6 months -- and they both always come up clean) whereas the "common user" has problems with viruses and scumware seemingly constantly, and that reason is education and not-so-common sense. The answer then is obviously to educate, and make that sense common.
    • 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 GODDA
      • Some people today simply DO NOT CARE to put forth the effort

        Lots of broad, generalizing statements. Those same people might care a lot about their family and visit their brothers and sisters regularly. They may also have a big savings account for an early retirement. Things you may not care about. I'd like to scream to you: "WAKE THE FUCK UP AND STOP MAKING STUPID GENERALIZING STATEMENTS!" at the top of my lungs.
      • American Gladiators is on 24/7 re-runs
        American Gladiators is back on the air!?!? SWEEEEET. What channel?
    • Look people do stupid shit, allway have, allways will; any "security measure", any "consumer education" that fails 0.001% of the time is failing enough to entice phishers with "get-rich-quick" dreams. There are ways to stop them, and that is to give them what they want, they want data sent to phishing pages we can do that

      First we can send masses of pseudo-random data to their site, we can bury them in data that they can try to process at 30 cents a transaction, or

      A name and address and a CC number that trig
    • >intellectual weakness:

      In other words, "pilot error".

      Part of the answer (I didn't say "solution") is browser UI changes to show people more of what's actually going on. Why can I connect to https://www.c1tibank.com/ [c1tibank.com] get a padlock icon telling me I've connected to the correct site, and NOT get the warning ssh would supply that I'd never talked to that site before?
  • by WebHostingGuy (825421) on Tuesday July 11, 2006 @05:37AM (#15696558) Homepage Journal
    A man in the middle attack will breach just about any security you have. Unless you can recognize it, or teach others to, this sort of attack will always work. The trick is that it is sophisticated and you have to educate people to know when they are connecting to the correct site or not; that is, check the URL and the SSL certificate when connected. And, never use self-signed SSL certificates.
    • Remind me again... why can't they catch the money? Why is there no way to tag cash and find where it ends up and lock that account up? My banking knowledge is limited, but it seems like if you can follow the cash you can get pretty good results.
      • 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 cha
        • Nah, I'm talking fish the phishers. Have preset bank accounts which are set to have any outward transers lock the account that gets the outward transfer. Find a fisher, give them the fake account. They fall for it and flags the offending account.
          • I like this idea a lot. Pursuant to someone who posted earlier about how dumb people seem to be, and how phishers pray on that dumbness, hey, there's a lot of smart people as well. I get phishing attempts multiple times per day. If I had a way to screw the phishers by sending them to a honeypot bank account, I would do it as a community service, and so would about a zillion other people who play here.
            • You know if you watch television for a while, you can collect quite a few Visa, Mastercard and Amexco credit card numbers and names that are not associated with a real person there are also numbers that always check good, some that always are bad some that are always over limit for testing. I'm sure if we all dug into it, there are also bank routing numbers and account numbers that are defined for testing only; it's not that hard to get the address to the local FBI Office so the possibilies for hilarious h
        • If you are in the US or UK, the identification procedures for new clients (KYC) are supposed to be quite painful. To establish a strawman identity for opening an account is possible but it definitely isn't easy. Most of the western world has similar information collection obligations, even traditional banking secrecy countries. So, for example, if I fished some details from your account and wired yor money to Switzerland, a complaint of wire fraud via the FBI to the Swiss Cantonale authorities will allow th
  • could the banks not create a usb card reader which you could put your debit/credit card into as part of the authentication, or even better an "authentication" card, it could have say 5 billion numbers on it and the system could ask for 5 digits randomly out of all of them, if the box was set to never send more than 5 digits then even if you fell for a phishing attack or got hacked those numbers would almost never be asked for again. This seems like such a good idea... I feel I must be missing something.
    • could the banks not create a usb card reader which you could put your debit/credit card into as part of the authentication
      They could not create it, but darn it they already have [wikipedia.org]. It's not wihtout it's problems as well.
    • Re:carding (Score:2, Interesting)

      by WedgeTalon (823522)
      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.
    • For the technology you're describing a "smart card", and there are various implementations of that, but none have caught on.

      For the crypto you're describing a one-time pad, and it has serious limitations, but there are better ways. The problem with a one-time pad is that they have to be generated and distributed securely. And you and your bank have to have identical copies of large files, which presents new security risks: anything that's duplicated doubles the possibility of compromise.

      Public-key cryptogra
  • Given that a wget command to retreive any session authentication key only takes a couple of seconds, a full minute window is easily enough.

    The phishers can also mimic the error path if the token is disallowed or mis-typed.

    This is not an easy problem to solve!

    • This is not an easy problem to solve!

      yes it is, after submitting transactions you must verify from your email account by responding to the email the bank sent you if you dont do this in 2 minutes the transactions are cancelled.

      so unless the phishers also hijacked your email account you effectively defeated them as you will see the mystery transfers you did not do before they are submitted.
  • by Colin Smith (2679) on Tuesday July 11, 2006 @05:51AM (#15696593)
    People might just be able to determine if they were valid or phishing attempts.

    Almost all email clients support s/mime these days, all you and the banks have to do is sign up to a certificate authority and install a certificate. They can be acquired for free.

     
    • 1. Certs are entirely too easy to obtain.
      2. Because of #1 the only thing a cert proves is that the hostname matches what's in the cert.
      3. Phishers have been using faked yet secure websites for years now they'll just switch to emails.

      Certs are worse than useless, they're misleading.
      • Bollocks.

        The problem with email at the moment is that forging From: fields is trivial, anyone who knows the first thing about SMTP can do it in 5 seconds and this means that an email can appear to come from any source the actual sender wants. I can send an email to anyone and make it appear as if it's from any bank in the world.

        With a signed email, if the sender(bank) email address in the From: field doesn't match the certificate then you know it's not from the real sender(bank). It's perfectly possible and
    • Sadly, some mail clients support signed and encrypted emails really badly (or not at-all). I have seen more than one installation of Outlook Express where, if a signed message is sent to them, you have to click extra buttons before it can be read, and you cannot reply-to or forward a message for some strange reason - I never did work out why.

      Sadly Outlook Express still has a huge end-user following as it is familiar, and comes-with "that" operating system. Using POP3 mailboxes means that migrating between m
    • You're underestimating the problem here. Banks can sign their e-mails using S/MIME until the cows come home and it won't do a thing to combat phishing. Phishing victims are naive and would not relate to the importance of checking for a valid S/MIME signature. They already have similar funcitonality in their web browsers with SSL and the "lock" icon and it's not working.

      As an aside, many banks are now using DKIM to sign their messages at SMTP time. It's up to the recipient to verify the signatures.
  • How about the other side of authetication - anonymity. There are cases when the service provider doesn't need to know personal or professional details about the customers, but nevertheless this kind of data is collected widely. The Shibboleth technology developed in the Internet 2 project in principle makes it possible for a customer to limit the access to personal data by service providers. This kind of solutions should be made widely available. Now there are all too many authentication systems collecting
  • Bank Security (Score:3, Insightful)

    by nighty5 (615965) on Tuesday July 11, 2006 @06:03AM (#15696623)
    As a security consultant I use lots of ways to defeat all types of security controls. and in true Slashdot way I didn't read the article. There is no silver bullet to security, it requires successive layers of controls (defence in depth) to adequately protect against attacks. It is no suprise to see two factor auth is defeated in this situation, but there is other controls a web application can use to safe guard against these attack types:

    Website Controls

    Additional "next PIN" for each transaction

    Challenge response

    Enter a PIN challenge based on dollar amounts to transfer

    The usual web security stuff - see OWASP for more

    Signing transactions with certificates and tokens

    Security Awareness

    Workstation security is paramount, firewalls, anti-spam, anti-malware, running as non-admin all assist in this process

    Some trojans imbedded into IE and pop-up boxes that sift the credentials upon the user typing in their banking website

    As you can there is so much you can do.
    Have fun!

    • Re:Bank Security (Score:2, Informative)

      by OP_Boot (714046)
      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.
    • A very good way to block man-in-the-middle attacks is one that has been
      described by another poster already, and which is in actual use by some
      banks: Introduce a second channel to verify the actual transactions. In
      the case described the bank simply sends a one-time pwd as an SMS to your
      cellphone, you have to enter the pwd to confirm the transaction. The
      attack used on Citibank customers (and my bank is using something similar)
      wouldn't work. With this method you won't need those very tedious
      systems where you h
      • This method was briefing covered on point #2 - challenge response..

        Unfortunately slashdot is not the avenue to discuss such matters as security, as it tends to be complex and depending on lots of factors.

        But yes SMS messaging is something that covers the "something you have" (token/mobile), along with "something you know" (password/pin).

  • Nothing surprising (Score:5, Interesting)

    by arivanov (12034) on Tuesday July 11, 2006 @06: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.
    • If you require client-side certificates, you can't bank from any machine you want, only from a particular machine. Because in order to prevent man-in-the-middle attacks, your client certificate has to have the IP address of your machine in it.

      Actually, if your provider doesn't even assign static IPs, you can't really use client certificates at all.

      For me, the major takeaway from this is that a fool and his money are soon parted, no matter how much technology you try to use to prevent it. Or, another way, no
  • by wfberg (24378) on Tuesday July 11, 2006 @06:07AM (#15696633)
    Let's see

    1) the website is simply at another address, well-educated users will spot the lack of https and the different URL
    2) I have an account at postbank(.nl) which uses a password for logging in, and then additional codes for transactions. The password will only give you read only access.
    3) At this same bank, the transactions are verified by sending you a text-message; not the most secured channel, but the message doesn't just include a "transaction acceptance code", but also the amount of money being transferred. If something is amiss it's spotted easily through this second channel, beyong the phishers' control.
    4) Another bank, abnamro.nl, lists the IP number you were last logged in from on the welcome page.

    I feel that 1) could be attacked by phishers using malware, so that's no guarantee.
    Using the amount of money to be transferred as part of the challenge is trivial and should simply be implemented at first opportunity. One of citibank's problems is that they're using a token that simply displays a code, rather than a challenge response system; no way to enhance the challenge..
    Number 3) is also pretty neat. Reall, I don't care so much about my bankstatements per se that they need to be protected with two-factor authentication (though of course in the US, identity theft might make this more prudent). The ability to check my account without too much rigmarole is very user friendly.
    Number 4) would be neat, but also confusing to many users, especially those behind DHCP.

    Sum conclusion;
    use challenge response, with the amount to be transferred firmly embedded in the challenge, or communicated to the user out-of-bounds.
    • 1) well-educated users won't fall for phishing
      2) Citibank uses the system from vasco.com. So now I need to enter 3 passwords. 1 for the site, 1 for the machine and the nymber that the achines gives me. None can be the same like my pin number.
      3) In Belgium sending text messages is not cheap. I will be the one paying for it. No thanks.
      4) At Citibank you also get a popup from you last login. Like I ever looked at it or rememeberd when I did log in the last time and if this is correct.

      The problem is the man in
  • by Anonymous Coward
    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.

    -m10
    • 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 nev
  • by Parandor (779995) on Tuesday July 11, 2006 @06:43AM (#15696722)
    Why is online banking allowing you to create new billing accounts online? Why can you make a transfer to a new, unlisted, account online? Answer: Banks want to save money.

    Most people almost never create new billing and transfer "destinations". We could afford to go in person once or twice a year to do this. The very few who need these options are usually kwolegeable about security issues. Even if they are not, the fact that there is so few of them is a protection in itself. Remove these options from online banking and even a "phished" account will be of limited use to the phisher since the only thing he can do with it is pay your bills.

    This solution was actually implemented in the beginning of online baking. The idea of pushing "new" features with no regards to their actual impact is almost like a disease in the current corporate world.
    • by ndg123 (801212)
      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.
    • I resist writing paper checks as much as possible and I seem to create a new billing destination for online bill pay, probably one per month, sometimes more, sometimes less, but easily 12 per year. Some are changes -- our pediatrician changed billing systems and changed the billing account and address -- but some are new, almost single use payments for magazine subscriptions and other stuff.

  • I suspect that we're only going to see some serious efforts to fix/curb this problem once the banks become 100% liable for monetary losses due to fraud. For the moment, their attempts to "fix" things are more of a PR exercise (for consumer's benefit and regulator's benefit) than an actual solution to the problem.

    At some point, the naughty people have to pick up the money. There needs to be more international coordination for prevention of bank fraud so that these criminals can't hang out in countries with
    • The regulatory action in the USA to encourage banks to improve authentication is an attempt to short-circuit the possibility of a major shift in liability, which could have a lot of unintended consequences for both banks and consumers.
  • Matrix card (Score:3, Insightful)

    by Tarrio (151332) on Tuesday July 11, 2006 @08:01AM (#15696954) Homepage

    My bank uses a two-factor authentication system, the second factor being a card with a 10x10 matrix of double-digit numbers. When you login, the website asks you for your username, PIN and the number which appears in certain coordinates in the matrix card.

    It used to ask you for it in the login page itself. Nowadays you need to have a mobile phone number associated with your account; when you try to login, the coordinates are sent to you by SMS. In that way, even if a phisher gets your username, PIN and full matrix, they cannot login because they don't know what coordinate is asked to you (and you receive the unsolicited SMS, so you can alert the bank). They would have to steal your cellphone too.

    Ah, and you have to enter those numbers using an on-screen keypad which moves around randomly anter you click on each number, so keyloggers are now useless too.

  • 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 fdiskne1 (219834) on Tuesday July 11, 2006 @08: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.

  • I see folks from scandianvia posting here about their banks offering security measures that far exceed what a typical US bank would provide. Are there any US banks that have more extensive security procedures than just a four to six digit pin? Like two factor, or email signing or what have you?

    -c

    • My bank has gone to a "registered" computer (seems to be a cookie), a login name, a user specific greeting, a user chosen image and a reasonable strength password (>=8 chars, must include both alpha and numeric). My insurance company moved to a login name and a decent password (>= 6 chars).

      In contrast my 401K plan, arguably the most important for the future, uses my SS and a four character password.

  • by Temujin_12 (832986) on Tuesday July 11, 2006 @09:47AM (#15697497)
    ...and I'll keep on saying it.

    If email encryption and certificates were a *STANDARD* feature by the major email clients (desktop and web based), then institutions could set a blanket policy that any email communication from them to their clients/customers must be encrypted and/or contain a digital certificate. Even better, these certificates could contain usage policies so that email clients could automatically filter/delete messages w/o the proper certificate or that don't follow stated policies.

    The trick is that the user needs to be abstracted away from the encryption/signing process so that they understand the basics of what encryption/certificates are but can use them with with just a click or two.

    A good example of taking security technologies and providing them to the user in a well abstracted form is TLS under HTTPS. IMHO, phishing would be drastically reduced if email encryption/certificates, along with usage policies, were as common and supported as TLS under HTTPS is today.

    [Pre-rebuttle]I am not saying that this will solve ALL phishing scams. I'm just saying that there are technologies out there that, if commonly supported and intergreted into email clients/services, would greatly increase the difficulty of pulling off a phising scam.[/Pre-rebuttle]
  • My bank (Score:2, Informative)

    by J0nne (924579)
    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, goo
  • by Distan (122159) on Tuesday July 11, 2006 @10: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 @12:27PM (#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 jc42 (318812) on Tuesday July 11, 2006 @01:30PM (#15699369) Homepage Journal
    I can't help but notice that all the authentication schemes being discussed are basically way that the bank verifies the customer is who they say they are. But the issue isn't that; it's that the customer is being tricked into thinking that they're talking to the bank when they are actually talking to someone else (who may be talking to the bank). There is nothing that I see that helps the customer verify that it's actually their bank on the other end.

    The whole "phishing" thing is based on the fact that the bank's end can be spoofed, and customers have no reliable way to verify that they are really talking to their bank. A Man-in-the-Middle is simply a variant of this, in which the customer thinks they're talking to the bank, when they're actually talking to the MitM, who is talking to the bank.

    Adding extra stuff to better authenticate the customer is not going to help here. Confusing the issue by just talking about "authentication" doesn't help either, since it conflates the two directions of authentication into one, and people don't notice that the customer may not have authenticated the bank.

A large number of installed systems work by fiat. That is, they work by being declared to work. -- Anatol Holt

Working...