Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security IT

Defeating Virtual Keyboards and Phishing Banks 135

Posted by Zonk from the sounds-like-a-full-night dept.
An anonymous reader writes "Noam Rathaus writes on the SecuriTeam Blogs how most Image Click-Me virtual keyboards schemes used by banks to fight phishing trojan horses can be easily broken, even (and especially) when encryption is used. He then discusses how screenshots of the pointer location are over-kill, and describes how to kick these security measures out of the way." From the article: "Instead of sending the remote image and waiting for the key-stroke information to be sent back to the server (the technique which the screenshots for pointer location on-click described above was used) some banks send the PIN number in cleartext, while others encrypt them, one such example is cajamurcia. Even when the encryption is used, banks tend to implement it badly making it easy to recover the PIN number from the encrypted form. I investigated a bit more on how cajamurcia handles such PIN strokes (with virtual keyboards) and I noticed something strange, they take the timestamp of their server (cajamurcia) and send it to you - this already posses a security problem - and this timestamp is then used to encrypt the PIN number you entered"
This discussion has been archived. No new comments can be posted.

Defeating Virtual Keyboards and Phishing Banks More

Defeating Virtual Keyboards and Phishing Banks

Comments Filter:

  • dumb (Score:5, Insightful)

    by Lehk228 ( 705449 ) on Monday November 27, 2006 @12:59AM (#16998488) Journal
    the whole idea is dum, you are trying to make a compromised host somehow "Safe" by obscuring what is going on. if they wanted to be really safe they would use a trusted device and allow the computer to simply be one more untrust part of the cloud between that device and the bank. a USB "smart card" could do the trick just fine. for added security have a pin pad on the smart card itself.
    • The banks don't do this because those Secure Cards cost $$$$$$ and that will hurt the banks bottom line. The EU, USA and Canada should force banks to issue these cards.

      • The banks don't do this because those Secure Cards cost $$$$$$ and that will hurt the banks bottom line.

        Some banks do it. ETrade, for example, will give you an RSA SecurID keyfob [rsasecurity.com] for free if you have over a certain amount of money in your account with them (like $50k I think, maybe it was 25). If you don't have enough money to get one for free, you can still get one from them for, I think, $25.

        • Re: (Score:2)

          by sr180 ( 700526 )
          But they wont protect against 'Man in the middle' attacks such as most typical phishing attacks. The bad guys simply ask for the SecurID code as well as the login details, and simply drain the account immediately, before the SecurID code expires.
      • Why not simply allow customers to choose whether or not they go with a bank that uses them? Given that there does exist such banks, its simply up to the user how much securing their bank account is to them. They can choose a cheaper, but less secure bank or a more expensive, but more secure bank. Why make the government force people to do it? Wouldn't that be like forcing people to have a password on their computer?

    • Re:dumb (Score:4, Insightful)

      by arivanov ( 12034 ) on Monday November 27, 2006 @02:18AM (#16998796) Homepage
      Ahem. Exactly.

      Client side x509 certificates (if possible on smartcards or tokens) will solve 99% of phising problems once and for all. For most "secure" sites, the clients authenticate the server (which can often be circumvented by using DNS tricks). At the same time there is no SSL level client authentication. As a result stolen credentials can be reused on another system. A smartcard holding the x509 cert prevents this outright.

      Unfortunately instead of using what is right there in front of them in the actual protocol spec the banks go into all kinds of technological roccocco. Not surprising actually. I tried to explain the concept of client side certificate to one of my collegues who had in the past implemented the internet banking system (and its security) for one well known UK bank and is now to implement another one. No matter how hard I tried, he could not grasp the concept.
      • amen to that. it shows exactly what's wrong with the IT industry in general. skill and experience mean nothing in the face of the overwhelming number of bullshitters out there trying to sell their crap services. i've stated repeatedly that the only way to get banks to take phishing seriously, is for the government to pass laws putting the cost of recovery of your money on the BANKS. do that, and it'll stop phishing over night. fuck their bottom lines, you'll find no pitty in my heart for those assholes maki
      • I still fail to see how anything attached to your computer or being entered through an input device will safely bypass the malware, spyware that is installed into your boxes. It's not not "mission impossible" to write snoopers for smartcards or usb controllers, or even to shadow redirect your ssl connection calls, once these are caught, the hacker won't give a **** if you are entering the security details with your nose on a laser keyboard on the kitchen sink.

        Unless your machine is secure, there's

        • Re:dumb (Score:5, Informative)

          by theCoder ( 23772 ) on Monday November 27, 2006 @08:12AM (#17000416) Homepage Journal
          If you use a smartcard, the crypto happens on the card itself. The private key never leaves the card. Simply speaking, a request is made to the card to sign something, and it gives back the signature. This means that no one listening on the computer can duplicate the authentication (assuming there is nothing else wrong with the protocol, such as replay attacks, any sort of man in the middle, etc).

          In essence, the smartcard idea is assuming that your machine could be compromised, and is moving the authentication to another machine (the smartcard) which is much harder to compromise.

          • Does this prevent man-in-the-middle attacks (possibly with the "man-in-the-middle" running on the same machine as spyware) in any way shape or form? You only need to authenticate once to do a lot of damage.

            • Re: (Score:3, Informative)

              by arivanov ( 12034 )
              Yes it does, provided that the system is correctly designed and implemented. In fact it is nearly bulletproof against a MIM.

              The MIM will need to have both a valid server certificate to authenticate to the client a valid client certificate to authenticate to the server. If the server correlates certificates with another credentials like a username and password (2+ factor authentication) it can immediately detect that a stolen identity is being used with the wrong smartcard.
              • So what exactly is this protecting against, that a standard SSL connection with dh-key exchange won't do if you present a user/pass anyways (besides propagating the capacity to properly authenticate elsewhere)? If there is malicious software installed it protects against nothing, correct? The malicious software could still hijack the connection. With SSL you have no chance of MIM if credentials are verified. Why not just save some money and give everybody a CD that verifies the security certificate in a

                • Re: (Score:2)

                  by arivanov ( 12034 )
                  With SSL you have no chance of MIM if credentials are verified. This is the exact problem - you can register InsertBankNameHere-secure-banking.com, get a cert and set up a simple forwarder that will forward all requests from users to the real website and back. After a few runs (and a few simulated IIS errors) you can have the pin and all the rest. There is no defence against this because the attacker can obtain a cert from the same CA (or equally trusted). Having client side certs protects against that beca
                  • It doesn't take long to initiate a money transfer over the internet, therefore I don't really see much of an advantage as far as malware goes. That aside, obviously there is a bit more security in the fact that the user can't screw themselves over as easily (assuming that both keys aren't included in the chip). Just as long as these financial institutions look at cross-platform compatibility I'm fine with it.

      • Re:dumb (Score:5, Insightful)

        by swillden ( 191260 ) * <shawn-ds@willden.org> on Monday November 27, 2006 @09:24AM (#17000952) Journal

        I've been in the business of designing, implementing and selling smart card-based security solutions for nearly a decade now, and I've talked to lots of banks about these issues. Most of them understand perfectly well that smart cards with client-side digital certificates are an excellent (though not perfect, see below) solution from a security standpoint. The reasons they aren't gung ho about deploying such a solution are (1) cost and (2) consumer acceptance.

        Smart cards themselves aren't expensive, and neither are smart card readers. The cost of retooling the card issuance process to support smart cards, however, is non-trivial, and the cost of deploying card readers to consumers and supporting them through the installation and usage process is very large. The biggest problem, though, is cardholder training. How do you teach millions of people how to use the thing, even if it's already set up on their machine? Simple problems like how to insert the card into the reader are surprisingly hard to address on a large scale.

        The UK, and a few other countries, are much more prepared for this than the US thanks to the Chip & PIN initiative that their banks have spent tens of millions on. At least UK citizens know to put the card in chip-end first, with the chip up.

        In any case, though, it's the cost and difficulty of getting consumers to deploy additional hardware on their computers that holds banks back from doing it, not lack of understanding. All of their weird security solutions are attempts to perform semi-secure transactions on the PC hardware that the cardholders already have, with no new software or hardware to install or maintain. Note that the costs and difficulties I'm talking about aren't theoretical. Various banks in different parts of the world have run pilots using these technologies, and they've invariably fallen flat. IMO that's because the pilots were poorly run, but having seen the failures, banks are very leery of trying anything else.

        The new buzzword that's sweeping the financial industry these days is Near-Field Communications (NFC). NFC is basically a contactless smart card chip embedded in your cellphone. The chip can securely store and use keys, and the interface with the phone provides it with a display, keypad and Internet connection so the chip can phone home to the issuing bank as needed (for velocity checking, balance checking, etc.). Assuming the phone can be protected from viruses, trojans, etc., and can be considered a relatively secure device, this has all sorts of advantages. It can be used in a retail environment with a contactless smart card reader, using the phone's display and keypad to give the user a chance to verify the transaction details (the amount, mainly) on a device the user trusts. For on-line usage, you can connect the phone to the PC via USB, or via a contactless smart card reader for secure and easy transaction, but it's more likely that you'd use the phone's data link for the financial transaction. Imagine going to amazon, picking out your goods, hitting the "buy now" button and then waiting a few seconds for a message to arrive to your phone, requesting payment authorization. You'd review the transaction details on your phone screen, authorize payment with the keypad, and the smart card chip would then create a cryptographically-secure payment authorization message and deliver it to either the bank or the merchant (depending on how the system was structured).

        What's actually going to happen? After failing repeatedly over the years in my prognostications, I won't even guess. I will say, though, that banks are big fans of "good enough", and that their definition of "good enough" doesn't require that fraud be impossible, only that it be sufficiently limited that it's affordable.

    • Re: (Score:3, Interesting)

      by ArsenneLupin ( 766289 )

      for added security have a pin pad on the smart card itself.

      Actually, that's not added security, but essential security. If the PIN was entered on the computer, and then sent to the smartcard for encryption, then a Trojan could still get it on that first leg of communication, before it was encrypted.

      For real security, not only would the PIN need to be entered on the card itself, but essential transaction data (amount, target account) would need to be displayed by the card as well (using a pocket-calculator like LCD display, for instance). Indeed, without such displa

      • Re: (Score:3, Informative)

        by jrumney ( 197329 )

        Actually, that's not added security, but essential security. If the PIN was entered on the computer, and then sent to the smartcard for encryption, then a Trojan could still get it on that first leg of communication, before it was encrypted.

        The way these things usually work, the PIN entered at the keyboard is not the PIN for the bank, but the PIN to decrypt the certificate on the smartcard. So knowing the PIN is only useful to the identity theives if it can get physical access to your smartcard.

        • Re: (Score:3, Informative)

          by ArsenneLupin ( 766289 )
          The way these things usually work, the PIN entered at the keyboard is not the PIN for the bank, but the PIN to decrypt the certificate on the smartcard. So knowing the PIN is only useful to the identity theives if it can get physical access to your smartcard.
          Correct. However, once the Trojan Program has the Pin, it will be able to reuse that to submit fake transactions if the user is careless enough to leave the card in the reader...

          • Correct. However, once the Trojan Program has the Pin, it will be able to reuse that to submit fake transactions if the user is careless enough to leave the card in the reader...

            And not much carelessness is required, either. The trojan could easily perform a couple of unauthorized transactions each time the card was inserted to perform a real transaction, and the user wouldn't notice.

            There are some workarounds to this, though. For example, the card can be configured so that it will only perform one transaction per insertion. The trojan could still do a bogus transaction when the card is inserted, but at least there'd be a clue to the user that something funny was going on.

            I

            • Re: (Score:2)

              by Sanat ( 702 )
              "The most popular use of stolen numbers, in the US at least, is buying gasoline, because you can do that without any human interaction and, at most gas stations, without getting your picture taken."

              I just completed a round trip vacation driving from Ohio to Sedona,AZ and back for a total of 5,000 miles driven. At about half of the gas stations where I bought gas had the pump requesting the entry of the Zip code when paying with a credit card.

              If you don't know the Zip code then no dispensing of gasoline. Thi
              • What kind of credit card do you have? Many gas stations (and other stores) require my zip when I use my AMEX, but I've yet to see anyone ask for it when I use Visa or Discover (I don't have a MasterCard).

                • Re: (Score:2)

                  by Sanat ( 702 )
                  My main card used for gasoline purchases during the trip was a VISA card. I used it at all stations except those that failed to read it properly at the pump. This occurred two times during the trip as I recall.

                  Mostly I was traveling on the interstates... I-40 mainly and stopped at the truckers stops such as Love's, TA, Pilot and Flying J.

                  As a side note... I just received my replacement Visa card from Wells Fargo Bank and it came in a foil lined envelope so i assume it contains a RFID of some sort. I put it

                  • I just received my replacement Visa card from Wells Fargo Bank and it came in a foil lined envelope so i assume it contains a RFID of some sort. I put it in my sock drawer and it will probably stay there.

                    It's an EMV-compliant contactless smart card, and there's really nothing to be concerned about. Not so much because of the technological security (which isn't being used in the current contactless cards being issued in the US) but because of the fact that Wells Fargo accepts 100% of the liability for an

                    • Re: (Score:2)

                      by Sanat ( 702 )
                      Thanks for the feedback on the EMV card. I must admit that i am not staying up on the newest technology used by banks and consumers.

                      It is nice to see someone on Slashdot who knows what they are talking about and is willing to take the time to share the wisdom.

                      I validated your points in research as follows:

                      "The company says 10 issuers have put the chip into their cards. Among them is Wells Fargo, which is issuing a Visa-branded credit card with the MicroPass contactless chip."

                      "The MicroPass chip does not hav

                    • "The MicroPass chip does not have the onboard cryptographic co-processor required for contactless EMV transactions. (2006-11-06)"

                      That statement is only half-correct, actually. EMV transactions don't require crypto coprocessors. EMV provides multiple operation modes, starting with one in which the card serves up what is essentially just magstripe data. The others are "static data authentication" (SDA) and "dynamic data authentication" (DDA). SDA is basically just a copy of the magstripe data plus a digital signature from the issuing bank, which the point-of-sale terminal can validate. DDA is the only mode that requires a crypto

  • Its a bit overkill, but I'm wondering if it could be broken short of a screen cap?
    What if the user was presented with a randomized "number pad" image and the user was asked to input their pin on their number pad but using the layout presented on the screen. The packet might contain: 6689 as the pin, but in reality it would be translated on the server side to 3327 using the image they were served at the time of page creation. Its unsophisticated, but I'm sure someone here could turn it into a beautiful inte

    • Re: (Score:3, Interesting)

      by iamdrscience ( 541136 )
      I use ING direct and they do something sort of like that, they have a picture of a numeric pin-pad that comes up and each key has a (random) letter on it. You enter your pin by typing the letter associated with each number. Unfortunately, you can also enter your pin by clicking the numbers (well, unfortunate for security, but fortunate for user convenience).

      • Re: (Score:2)

        by crossmr ( 957846 )
        Its better. Do you know if they actually decode it server side? Because that would be one of the keys. If they could create it so that the snooper had absolutely no access to the correct key or the method by which to decrypt it, thats about as secure as you can make it. Using a random pattern like that would ensure they couldn't create an algorithm or anything like that to figure it out. Clicking would have to be disabled as much of a pain as that is.

        • Re: (Score:2, Interesting)

          by fatcop ( 976413 )
          I use ING Direct and noticed that recently. Its pretty much exactly as the first parent described. Though I don't see anything about keyboard typing being allowed. Its pure mouse clicks only for me.

          This is what I gather from using it and glancing at the page info and scripts:

          The keypad numbers (are images) and are randomised (threw me first time, but no probs since) every login session.

          Every time you login each number corresponds to a different image URL on the server. The URL's format is like http:// [mybank.ohyeah]

          • I don't see anything about keyboard typing being allowed. Its pure mouse clicks only for me.
            You can type it in if you want, the instructions next to the pinpad specify it:
            "Use your mouse to click the numbers on the keypad that correspond to your Login PIN.
            OR
            Use your keyboard to type the letters from the keypad that correspond to your Login PIN."

    • Re:What if you obscure the pattern? (Score:4, Interesting)

      by uhlume ( 597871 ) on Monday November 27, 2006 @02:11AM (#16998770) Homepage
      Grid Data Security's GridOne uses a very similar approach: they present an on-screen alphanumeric entry grid, with each character surrounded by four randomly-generated numbers, one in each corner of the cell. Users enter their password by typing the corresponding number for each character of the password, from a pre-selected corner of the cell (upper left, lower right, etc). Since the numbers are randomly generated with each display of the entry grid, and any numeral may appear in multiple places on a given random grid, this effectively defeats both keyloggers and screengrabbers: even if you can see both the entry grid and the entered keystrokes, deriving the user's password from that information is non-trivial.

      http://griddatasecurity.com/Approach.htm [griddatasecurity.com]

      (Of course, this isn't much use against the hypothetical of a carefully-engineered realtime man-in-the-middle attack, but I suspect very little would be.)
      • That's a remarkably elegant system which (depending on how you establish the password) pretty much defeats any kind of screen scraping technology.

        It seems even better than the banks that mail out one-time password cards.

        If we could convince a bank to actually send out cds with their certificates and a certificate for each user then it'd be almost infallable.

        Until of course the phisher sets up a page that says "For verification purposes we'll now ask you to type your password once a month..."

        sigh

        • That's a remarkably elegant system which (depending on how you establish the password) pretty much defeats any kind of screen scraping technology.

          Unfortunately it doesn't defeat brute force attempts but rather helps them. In their example, the password is "Grid1" which if we assume the available characters are 0-9, A-Z, and a-z results in a possible 62^5 possible permutations. Replacing the characters with numbers results in the password having only the characters 0-9 which results in a possible 10^5 permutations -- almost 10,000 times weaker. I suppose that's yet another demonstration that security boils down to a series of trade-offs.

          • Re: (Score:2)

            by uhlume ( 597871 )
            That's a much more reasonable analysis than the Mastermind comparison. However, in the real world, brute force attacks are trivial to impede simply by locking out accounts above a certain threshhold of failed logins. I don't know of a single online banking system that doesn't implement this.

      • Since the numbers are randomly generated with each display of the entry grid, and any numeral may appear in multiple places on a given random grid, this effectively defeats both keyloggers and screengrabbers: even if you can see both the entry grid and the entered keystrokes, deriving the user's password from that information is non-trivial.

        Unless you observe multiple logins, in which case matching up which numbers correspond to which letters becomes nothing more than a game of MasterMind. [wikipedia.org]

        • Re: (Score:2)

          by uhlume ( 597871 )
          Really? Care to explain how that works when the corresponding numbers change with each login?

          • Really? Care to explain how that works when the corresponding numbers change with each login?

            I'm assuming the attacker has a screenshot of the grid with the letters and numbers for each time and that the password doesn't change. Each of the 62 characters (A-Z, a-z, 0-9) has 4 numbers out of 10. So there's a 40% chance that a given number is on any of the characters. This means that, on average, 40% of the characters have that number. Rounding up each time, that's 25 possible matching characters for each character of the first login. After observing the second login, there's a 40% chance that e

            • Re: (Score:2)

              by uhlume ( 597871 )
              Your logic might hold true if each letter corresponded to one and only one randomly-generated number. Remember, though, that the cracker doesn't know which of the four random numbers associated with each character is significant. Coupled with the ability to inject "decoy digits" into the stream, I'd have to consider this system sufficiently difficult to compromise. If you really wanted to complicate things, you could use a hex-based grid (for six associated numbers instead of four), or use a combination of

              • Your logic might hold true if each letter corresponded to one and only one randomly-generated number. Remember, though, that the cracker doesn't know which of the four random numbers associated with each character is significant.

                Read again -- I take this into consideration. The odds that one corner of a given character contains the number in question is 1 in 10. There are four corners, so the odds that the number in question is on a particular character is 4 in 10, or 40%. My analysis is unchanged.

                Coupled with the ability to inject "decoy digits" into the stream, I'd have to consider this system sufficiently difficult to compromise.

                I'd have to think about this a little more, but my initial impression is that the decoy digits don't significantly increase the difficulty of attack. However, I'm not certain on this point so I'm willing to be corrected. What I'd lov

                • As you increase the number of digits on any given character you also increase the possibility of false matches. For example, if each character had all ten digits on them, you could enter any combination of the right length to login since any number you enter would match every character (ignoring the fact that it's random so you wouldn't be guaranteed each digit only once, but you get the idea).

                  Bah... I'm on crack. Of course, you're only choosing one position out of the ten... not that all ten numbers are in the same position. With ten positions, you're looking at 40 observations. Extending the existing system to eight compass positions, for example, it would take an average 19 observations to deduce the password. Why not just go all-out and make each character into an analog clock. Instead of choosing a corner (eg: upper-right) you could choose a time (eg: 7 o'clock) and enter the number at

          • Just thinking about this further, it gets even worse. Assuming you know the background behind the system (where the user specified in advance to use the same unknown corner each time) then you can also improve by eliminating corners. It's too late to do the math on that as well, but you can probably shave off one or two observations by incorporating that strategy.
             

  • Secure banking? Yeah right. (Score:3, Interesting)

    by thedarknite ( 1031380 ) on Monday November 27, 2006 @01:07AM (#16998530) Homepage
    For institutions that are responsible for vast quantities of peoples money, some of the security policies they implement are really quite strange. For example, the bank I use, even before they brought in the annoying virtual keyboard, had a six character alpha-numeric limit on there passwords. Very bizarre considering that you enter in your customer id which is a ten character string.

    Although, on the plus side it has made me extra paranoid about all online transactions. So now any site where I am involved in a finacial transaction has different passwords and anything that gets cached is cleared out of my system as soon as I am done.

  • Meanwhile, back in the old west... (Score:3, Funny)

    by werewolf1031 ( 869837 ) on Monday November 27, 2006 @01:12AM (#16998554)
    this already posses [tfd.com] a security problem
    Round 'em up, boys! We gonna lynch us some bank robbers!

  • Yeah, and? (Score:3, Insightful)

    by iamdrscience ( 541136 ) on Monday November 27, 2006 @01:18AM (#16998574) Homepage
    So the article is saying that people with trojans on their computers are fucked? Is anyone surprised by this? The point of virtual keyboards is not to defend against trojans, it's to defend against keyloggers. They may defend against trojans that try to steal your account information with a keylogger, but I think it's safe to say that no matter what security technology your bank is using, if you've got a trojan on your computer you're going to be fucked.
  • I'd say just go visit the bank in person, it's probably right down the street, but of course it's not open. I don't care what type of bank it is, it's not open right now. Why? Because you're home and not at work, probably cuz it's a weekend. If banks really wanted to improve security, they'd actually be open at usefull times so you wouldn't have to rely on web services. But I guess that's all you can expect from a business where the less customers stop in, the more money they save (in staffing etc). I
  • It seems to me that having a 4-digit numeric password on a bank *website* is a pretty fatal flaw in the first place! Given a relatively large botnet and enough legit account numbers (much easier to come by than passwords), let's say 3 tries per account number, how long till you find someone with '1234', '4321', or '1337' ?

    Luckily, both my bank websites are protected by 8+ chr alphanumeric passwords. I would *not* stay with a bank that wanted me to use my card's PIN to log on with.
    • My guess is that before you hit on an account that had a password of 1234, 4321 or 1337 somebody in the bank's IT department would realize that something's up because a a ridiculous amount of accounts are hitting their password tries limit.
      • But assuming a perfectly random distribution, 1 in 10,000 accounts will have the password 1337. If you have 10,000 account numbers and 10,000 different computers to try them from then you can find one pretty damn easily.
  • The Royal Bank was down last week- they said it was "software problems" me thinks they were hacked of DDOS'ed.

  • No Surprise (Score:4, Informative)

    by daeg ( 828071 ) on Monday November 27, 2006 @01:45AM (#16998680)
    This is no surprise at all. Keyloggers will be a thing of the past soon enough for the major hackers.

    More scary is the fact that adding a simple network device will allow a virus to log all Internet traffic. Look at HTTPLook (a small app used to sniff HTTP traffic). It comes with a small HTTPS module that intercepts HTTP traffic transmitted via HTTPS.

    Using such a device will also help cut down on the amount of data hackers can get -- HTTP traffic is useless to them. Why do they care you went to Google and searched for "hot gay wrestlers"? They don't. HTTPS, on the other hand, will set off alarm bells -- if a server is worried enough about security that it pays for certificates, the data must be worth something, right?

    The solution is that logging into secure systems needs to require a physical presence. An older system I maintained a few years ago for the Mortgage industry used a username, password, and a key from a small business card in their wallet. Each month users received a new card, and each card had about 50 numbers on it. The system knew which numbers each user had and only allowed each number to be used once. Logging in with a wrong number would flag your account, repeated attempts would lock it. Yes, it increased support load when someone lost their card (the cards were unmarked so if someone found it, the numbers are useless), but it was fairly secure and generally a lower cost alternative to biometrics (and much more portable).

    This combines the "something you know" authentication scheme (username, password) and the "something you have" scheme (password card). The third type is "something you are" -- biometrics.

    (Failure point: person gets kidnapped. If a user gets kidnapped, security is the least of the worries until they are recovered. Failure point: if the database with the numbers is compromised, the system is no longer secure. If the database is compromised, they no longer need to log in, and no secret numbers will stop them.)

  • Cut them off at the pass (Score:3, Funny)

    by SEWilco ( 27983 ) on Monday November 27, 2006 @01:56AM (#16998722) Journal
    posses a security problem
    It depends upon your posse whether one or several of them are a problem.

  • Is it just me? Am I missing something? (Score:5, Insightful)

    by zappepcs ( 820751 ) on Monday November 27, 2006 @01:59AM (#16998732) Journal
    If your pc is infected with a trojan, or other malicious software, its feasible to capture the screen with each keystroke while connecting to a bank website and forward that data to a server somewhere at a later time... key logging doesn't have to be only key logging, it could be logging keystrokes and relevant screen data at the same time.

    The ONLY way to outsmart software that wants your data is to not load that software on your machine. I find that I feel much safer booting a life CD (DSL or Puppy or pick your flavor) and running to the banking website with a freshly installed OS... no chances for virii or malware etc.

    That is certainly easier than actually going to the bank... and I know that its safe.

    It at least makes me feel a bit safer.
    • Yeah, I know it is supposed to be LIVE CD. Spell checking doesn't always help...

    • Re: (Score:3, Interesting)

      by iamacat ( 583406 )
      How do you know you are not booting your life CD into a virtualizer run by your hacked EFI firmware?

      • Re: (Score:2)

        by GoofyBoy ( 44399 )

        Is this possible with non-EFI firmware/bios? Could you turn off/restrict more advanced features of an EFI firmware?

        • Re: (Score:2)

          by iamacat ( 583406 )
          Oh well, you could set the boot order to only hard drive in regular BIOS and set all the passwords that this particular BIOS allows to prevent the user from altering - or ideally even viewing - the setup. Then install, say, Linux with parallels and boot messages suppressed and you can boot user's "secure" CD and do all the key/network logging and screen capture you want.
  • This was an interesting article, but it got painful to read after a while. I would hope that SecuriTeam knows that PIN stands for Personal Identification Number.


    Now if you'll excuse me, I have to enter my Personal Identification Number Number into the Automatic Teller Machine Machine.

    • That's why in Pittsburgh, we call them MAC Machines. You ever see the ones that say MAC on the top (if you're from NY, NJ, or PA, probably)?That's "Money Access Center" so adding "machine" to the end works just fine.

  • My Phone is a Weapon (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Monday November 27, 2006 @02:03AM (#16998744) Homepage Journal
    I'd rather use an ATM by touching my mobile "phone" to it to pair it with my Bluetooth (and exchange keys), then use the phone to control my session. I'd prefer my phone client to generate onetime passwords consumed by the ATM to giving anyone my PIN.

    With that protocol, I'd feel safe even using those random ATMs at delis and various "impulse purchases", where today they get my PIN and can launch a replay attack any time they want.

  • Never develop your own crypto protocols (Score:4, Interesting)

    by Beryllium Sphere(tm) ( 193358 ) on Monday November 27, 2006 @03:01AM (#16998978) Journal
    Unless you're an expert crypto protocol developer and you're not going to deploy it to the field until it's had several years of peer review.

    That business with the timestamp? Offhand I'd say the bank was trying to do the right thing by preventing replay attacks. But using a timestamp? I'm having trouble keeping up with just the obvious attacks against that, let alone the attacks that a seasoned crypto developer would find.

    If you ever need to do what the bank tried to do, find something already written and battle tested, make sure its assumptions and security properties line up with what you need(*), and use that instead of repeating the last fifty years of protocol design mistakes.

    (*) Then you'll find that they assume trusted endpoints, which is something worth reflecting on.

  • Keyring Dongle (Score:5, Interesting)

    by bonhomme_de_neige ( 711691 ) on Monday November 27, 2006 @04:05AM (#16999256) Homepage
    HSBC in Australia and SE Asia (and, it seems, with a bit of Googling, elsewhere in the world) issue with online banking accounts a device that sits on your keyring that generates a 6 digit number when the button on it is pressed, and displays that on a small screen. The number is different every time.

    When you log in or do any transaction, you are required to enter this number (along with any other credentials which are appropriate). The bank records the serial number of the dongle they gave you, and I would assume that there is some secret mathematical algorithm that allows them, knowing the serial number and the time, to calculate what number your device will display.

    If you make 3 mistakes in a row with the 6 digit code, your internet banking account is automatically locked down, and you have to contact them to unlock it.

    Now, that's a very simple trick and I can't see how a hacker / phisher would get around it. Sure they can sniff the code when I log in, but 30 seconds later it will be useless. Short of mugging me for the device on my keys (after having phished my regular login/password), they can't get in to my account. Even if I leave a session logged in and walk away, and someone else sits down at the terminal, they can look at my balance and transaction history, but can't make any transactions.

    Having used the device for a year I have to say it is remarkably convenient, and it seems immune to most of the attacks described here, and doesn't have the convenience drawbacks of one-time PIN cards. Why is HSBC still the only bank doing this?

    More info on the device: http://om.hsbc.com.au/osd/ [hsbc.com.au]

    • Re: (Score:2, Informative)

      by Anonymous Coward
      erm, how would this protect against realtime phishing?
      e.g.
      user enters username/pass/magic number to log in at fake bank website
      fake bank website then uses that info to log in at real bank site and transfer $largesum to $evilguy
      if your token only changes its code every 30 seconds that shouldnt be hard at all
      btw, the same scam made a bit more elaborate would also work against one-time-use number pads (present user with fake 'enter transfer details and one-time-use number, use that number to do a different tra

  • Have a split PIN system (Score:5, Insightful)

    by caluml ( 551744 ) <slashdot@spamgoe ... g ['ere' in gap]> on Monday November 27, 2006 @04:49AM (#16999414) Homepage
    Have a split PIN system - half in your head, and a random second half texted to your phone, which is valid for 5 minutes after it is texted. Voila. And the bonus? Everyone owns one of these "what you have" devices (in the UK at least).
  • If the banks did care they would form an international alliance to track down the cash flow and put quick end to it.

    Except they already have two internal alliance groups in place called MasterCard and Visa. If both of them changed their merchant agreements so that any connection to phishing or domain fraud would result in losing the merchant account, you would bet ever domain registration company and hosting company in the would be checking things a whole lot closer. Even network solutions wouldn't last m

  • Solutions to stop phishing & trojans etc (Score:3, Interesting)

    by jonwil ( 467024 ) on Monday November 27, 2006 @05:42AM (#16999678)
    This solution would be OS and browser independant and would not be subject to any issues such as SMS's not getting through to a cellphone.

    Basicly, each customer is given a device that looks a bit like a small calculator, make it "solar" powered (in reality those panels will work just fine powered by any sufficiantly bright light source) so it never looses juce.
    It would have a 0-9 keypad and other buttons. Each device would contain a unique number that is also securely stored on the banks computers.

    When you want to log in, the bank generates a random number and displays it along with a form field for username/user ID/whatever, a form field for password and one for a hash. The user types in the random number into their calculator thing which is then hashed with the number stored inside it and the result displayed. The hash algorithim has to be chosen such that there is no one number that when hashed with any unknown stored number can produce either the stored number or something that you can get back the stored number from. (this prevents the hacker from feeding a chosen "random" number to the user and getting the stored number that way).

    Once you do that, the displayed hash along with username and password are typed into the form. The hash is compared with the same calculation done by the banks computer and if the username, password and hash match up, you are logged in.
    When you want to do a transfer to someone not on your "approved payees" list or add someone to the "approved payees" list, you have to enter the account number and/or dollar amount and/or another random number into the calculator thing which spits out another hash that has to be typed in. This prevents the phisher /trojan/whatever from changing the details of the transaction ($ amount or destination account).

    Unlike some other proposals (USB smart cards, mobile phones), it is 100% OS and browser independant and requires no drivers.

  • Banks and third-party Javascript (Score:3, Interesting)

    by timlewis_atlanta ( 195776 ) on Monday November 27, 2006 @08:32AM (#17000522) Homepage
    And this story breaks the evening after I notice that a large bank that I shall not name, but instead refer to "Bank of America", changes their SiteKey/Login page so that it now loads Javascript from a domain other than bankofamerica.com : "liveperson.net".

    I only noticed this because my "NoScript" Firefox extension started showing the "Script partially allowed" message.

    Now, I'm no expert, but I do know that Javascript has a bit of a spotty history when it comes to security. Having looked into liverperson.net it appears to be legit ; but in any case, I did not allow it access.

    But my question is this : why on earth do BofA think it makes sense to link off-site during the login process ? Surely this is completely nuts ?
  • Q: Does on-line bank fraud cost the consumer or the bank?
    A: In general, The Bank if you can prove it is not your fault. Otherwise, you, the consumer.

    If it was costing the banks millions of dollars each year (which it is if we believe the press), then a bank should be willing to spend $5 per on-line user to issue each and every one of them with an OTP should they not? Well, my bank in Aus (HSBC) thinks so. I do a lot of online banking, and I don't mind doing it from a public terminal, because I have an elect

Slashdot Top Deals

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce

Close