Defeating Virtual Keyboards and Phishing Banks

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"

Comments

dumb

[Lehk228]

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.

Re:dumb

[alunharford]

Even then, you're still far from safe.

All that somebody has to do is to make a trojan that waits until the user has logged on to their bank, and the fancy USB key has done its job. It notifies the attacker, who then logs into the machine via a backdoor, takes control of the mouse and keyboard and simply transfers the money where they want it. Most users will be far too slow kill their machine.

That's not exactly a difficult piece of malware to make!

Bottom line: If any important part of the transaction is done on a compromised machine, no amount of crypto is going to make it safe.

Re:dumb

[ancient_kings]

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.

Re:dumb

[Kjella]

If you have a secure device, you need secure confirmation. Personally I would prefer being able to use my cell phone. It has a trusted screen and a trusted keypad. Phone trojans are extremely rare, so let me punch in a transaction on the online bank, use IR or Bluetooth or WiFi or USB cable or even a damn SMS and let me click Yes or No (or even another PIN) on the cell phone. That should stop any phishing attempt, though I doubt my machine would get infected in the first place.

Re:dumb

[arivanov]

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.

Re:dumb

[iamdrscience]

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 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:dumb

[alunharford]

In most parts of the world, the banks are liable for the disappearing money.

Re:dumb

[mochan_s]

Phone trojans are extremely rare

Doesn't mean they always will be.

Re:dumb

[timmarhy]

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 making record profits every year, while some poor grandma gets screwed over of her life saving simply because banks can't implement a secure login. damn it understanding of technology should not be a barrier to safely accessing your money!

Re:dumb

[ArsenneLupin]

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 display, a smarter Trojan might highjack a legitimate transaction, and transform the data into something else (change your monthly rent payment into a huge transfer to scammer's account...), and the user would be none the wiser.

But, of course, a more sensible approach is to keep the host system secure. Why are some banks still forcing their customers to use Windows and Internet Explorer when these are known to have security issues?

Re:dumb

[Anonymous Coward]

the whole idea is dum Yes... yes, it is.

Re:dumb

[jrumney]

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:dumb

[ArsenneLupin]

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...

Re:dumb

[aussie_a]

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

[moro_666]

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 nothing that stops the hijackers. So scan it daily, be careful what you run or open (occasionally even linux boxes should be scanned for rootkits the least ...).

Re:dumb

[bogado]

But the cell network is not trusted. Sure this would make you safe from an attacker from the other side of the planet, but it would still be a problem for someone from your neighborhood.

Re:dumb

[theCoder]

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.

Re:dumb

[swillden]

Securing a communications channel is easy if you have trustworthy endpoints. I'm not so sure that the cellphone is a trustworthy endpoint, but if you can make sure it is, then having an unsecured network isn't a problem.

Re:dumb

[bogado]

If you have a compromised computer it don't matter anyway, the trojan could simply wait for you to log in, using what ever side channels are available and then take over the connection and place whatever fraudulent transaction they want.

But basically you are correct, if the cell is encoding everything correctly the connection could be trusted, the only problem is that cell networks are known for hiding behind obscurity for security, witch is not very safe after all.

Re:dumb

[swillden]

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:dumb

[swillden]

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.

In reality, while these trojan-based attacks against on-line smart card use are feasible, smart cards would make fraud vastly harder than it is now, and would be quite difficult to actually get away with. See, the thing about credit card fraud is that it's hard to actually get away with anything of significant value without leaving a trail pointing back to the fraudster. Not impossible, mind you, but there are some real limitations. Even with the present, completely insecure, system, buying physical goods with stolen card numbers is risky, because you either have to enter a retail establishment or if you order on-line you have to specify a shipping address. 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.

Smart cards eliminate fraudsters' ability to forge working cards, so fraudulent card-present retail purchases become impossible (without physically obtaining the card from the cardholder). For on-line usage, the fraud potential wouldn't really change, but actually perpetrating the fraud would be a much more difficult thing to achieve. The sophistication of the attacks would have to be much greater. That wouldn't make them impossible, but that's okay. The goal is to keep fraud to affordable levels, not to eliminate it.

Re:dumb

[swillden]

But basically you are correct, if the cell is encoding everything correctly the connection could be trusted, the only problem is that cell networks are known for hiding behind obscurity for security, witch is not very safe after all.

Doesn't matter. You wouldn't rely on the cell networks for any of the security, you'd just use the network as a transport. The Internet is also completely insecure, but we easily create secure communications channels over it. The security of the network is irrelevant. It's the security of the endpoints that matter.

Re:dumb

[Directrix1]

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:dumb

[arivanov]

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.

Re:dumb

[Directrix1]

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 more visible fashion. Additionally, it sure would be nice if there was a FDIC CA that financial institions would be required to use, and browsers could display their status in a more prominently visible way.

Re:dumb

[arivanov]

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 because the MIM is not in a possession of the private key. Even if it has successfully obtained a private key from one user it cannot use it for attacking other users sessions because the server will match the cert and the credentials and kick it out (possibly locking the user in the process just in case).

As far as malware on the user machine is concerned a smartcard/token is still an advantage. Even if the token does not have a secure PINpad the attack will be limited only to the time when the token is plugged in. If the token has a secure PINpad the attack will be limited only to the remainder of the current session. Once it is over the attacker cannot do anything until the mark logs in again.

Re:dumb

[Directrix1]

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

[sr180]

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.

Re:dumb

[Sanat]

"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. This does not stop all funny business but will stop most of it from opportunists.

Re:dumb

[swillden]

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:dumb

[Barryke]

My bank (RaboBank) has this. (a safe endpoint)

If i want to utilize online banking, i have to use a small calculator-like device. I have to insert my banking card, enter my pin code, and to complement that some random code the website hands me.
Then the device gives me a code to hand to the website.

The bank doesn't rely on computer safety. Looks like a quite secure endpoint to me.
Only risk could be one capturing your screen / watching over you shoulder, but that's everywhere and inevitable.

Re:dumb

[Barryke]

FYI: device manufacturer website: http://vasco.com/

Re:dumb

[bogado]

What I meant was that those same people that relied in flawed secret protocols to secure cell phones that ended up being easily cloned would be responsible to create those secure lines to banks. Many banks do send a confirmation via a simple SMS, being only a confirmation there is no problem since the idea is to make you call the bank if anything is wrong (this could become a phishing attack though), but I envision that a bank would send credentials via the same, unsafe, SMS system.

Re:dumb

[Sanat]

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 in my sock drawer and it will probably stay there.

Re:dumb

[swillden]

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 any fraud. That's a good thing for you because there are a dozen ways for fraudsters to get hold of your credit card number, all of them easier than via the RF interface.

In the future, the chip-enabled cards will make it possible for truly secure transactions to be conducted, so that it will be effectively impossible for anyone without physical possession of your card to conduct transactions using your account. If you care about credit card security, I highly recommend that you use the contactless card you have, because that will facilitate the deployment of more chip cards and the supporting reader infrastructure. Once all of that is in place, it will be a relatively simple matter to move to more and more secure transaction modes, arriving ultimately at payment systems that don't reveal your account number to anyone, and don't really make use of it anyway, so it wouldn't matter if it were revealed.

I know it's en vogue on /. to be skeptical of this stuff, but it really is good for security, not bad... increased security is *why* it's being deployed, even if the higher security isn't really implemented in the current generation of cards.

Re:dumb

[swillden]

I envision that a bank would send credentials via the same, unsafe, SMS system.

As long as the credentials themselves are correctly secured, it still doesn't matter if the SMS system is insecure. Note that what I'm talking about is embedding a secure crypto chip in the phone (which is already happening, BTW), where the cryptography is defined and implemented by the banking industry, not the phone industry. The proper solutions to these security issues are very well understood as evidence by their implementation in industry standards like EMV.

Re:dumb

[Sanat]

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 have the onboard cryptographic co-processor required for contactless EMV transactions. (2006-11-06)"

http://www.cardtechnology.com/article.html?id=2006 1106R8P5YA7J

Re:dumb

[swillden]

"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 processor, because the terminal and card conduct a cryptographic challenge-response protocol.

The other major security measure that EMV recommends, and which is not implemented, is the use of a PIN to authenticate the cardholder to the card and "activate" the card. The PIN replaces the use of the handwritten signature, which is the present form of cardholder authentication.

Thanks, by the way, for making me go do a little research. It appears that the MicroPass chips are not, in fact, EMV-compliant. They aren't even using the insecure EMV modes. They are ISO-14443, T=CL chips, communicating via standard APDUs, but the data packet they return is just a copy of the magstripe image, not an EMV-compliant data packet. The reason they're doing that (not that I think it's a good choice) is that it allows them to make cheap readers that look to the point-of-sale system just like a magstripe reader, meaning that none of the POS or back-end infrastructure has to be changed.

As I said before, current credit cards are already so insecure that this doesn't really change the situation. The one issue that concerns me is that I haven't been able to confirm that the readers being deployed are upgradeable to handle the real EMV transactions. If they are, I call this progress, even if it's perhaps less progress than I would have chosen to implement if they'd asked me. The cards get reissued in three years anyway, so they can be upgraded as part of the normal replacement cycle (arguably, more secure cards don't need as frequent replacement, and smart cards are more durable than magstripe cards, so we could easily have cards that are issued every five to seven years, but banks find that consumers use a card more in the 6-12 months after it's replaced, so they prefer a shorter card lifetime. Marketing).

It's the reader infrastructure that really needs to be deployed. Once the readers are out there, retailers and merchant acquiring banks can begin updating the backend infrastructure piecemeal to support the EMV protocols. Then if the readers can be upgraded to deal with new, EMV-compliant cards, we can gradually move to a much more secure credit card infrastructure.

IF the readers can be upgraded. Hopefully they can at least accept firmware upgrades. I wouldn't put it past the reader vendors to save a few bucks by making non-upgradeable readers, nor would I put it past merchants and merchant acquirers to fail to ask about the future, even while they think they're moving toward it.

Avoiding keyloggers

[Anonymous Coward]

You only need a virtual keyboard to avoid the security threat posed by keyloggers.

Keyloggers that do exist in the wild are all keyloggers for Windows.

I would be very annoyed if my bank decided on a virtual keyboard approach to security and put me at risk to this potential exploit when I have my own reliable method of avoiding keyloggers ... I don't run Windows.

Re:Avoiding keyloggers

[werewolf1031]

I believe you're thinking of software keyloggers, in which case you're (probably) correct. However, to the best of my knowledge, a hardware-based keylogger (dongle between keyboard and port) doesn't give a rat's ass what your OS is. Then again, if someone has both physical access to your computer and motivation to spy on your online transactions, your bank's online security may be the least of your problems...

Re:Avoiding keyloggers

[iamdrscience]

As far as keyloggers installed by trojans, you're probably right, I've never heard of that happening with any OS besides Windows, but there certainly are keyloggers for unix and other OSes and while you probably don't have to worry about those (presuming you keep your PC secured), there are also hardware keyloggers.

Re:Avoiding keyloggers

[lostguru]

of course i would like to see you try to put a hardware keylogger on my iBook (it runs fedora and mac) or my iMac's bluetooth keyboard. Course bluetooth would prolly be easier to keylog wirelessly

the parent makes half of a good point, but even then windows can be secure if you are smarter than the average bear.

long answer is DING! DING! don't bank online. Walk, Bike, Hitchhike, or Drive TO THE BANK, and when online don't assume anything is secure, your just in for a supprise

Re:Avoiding keyloggers

[Funkcikle]

don't bank online. Walk, Bike, Hitchhike, or Drive TO THE BANK, and when online don't assume anything is secure, your just in for a supprise

And leave myself open to criminal attack? No thank you, sirrah! Banks are always being robbed by masked men!

Re:Avoiding keyloggers

[Anonymous Coward]

I do keep the PC physically secured. There is no risk of a hardware keylogger for this machine, and even if there were the machine is behind a hardware router & firewall (so any hardware keylogger would see no route to the internet). I also only install software that is auditable, and which is in fact audited by many eyes other than the authors, so there is no malware trojan on the machine. AFAIK, there are no "active" viruses known that can infect the OS I use. The various virus scanner companies have long tried to find such live malware to try to convince that their virus-scanner software is a must have, and so far they have not come up with anything.

If an external party tries to telnet/ftp/browse to my IP address, they end up at the router, not at the PC.

Since the machine has no Windows software running to exploit, I have a very good defence against keyloggers and other malware that would need to run on the local machine.

I have much less defence against any measure that tried to use my browser as a "security" layer. Virtual keyboards from banking sites turn out to be a far greater risk to me than the keyloggers they are trying to protect me against.

I would much very prefer if they didn't try to "help" in this misguided way.

Re:Avoiding keyloggers

[denebian devil]

long answer is DING! DING! don't bank online. Walk, Bike, Hitchhike, or Drive TO THE BANK, and when online don't assume anything is secure, your just in for a supprise.

For most people, the likelihood of an offline attack on their bank account (loss of a debit/credit card, stealing of the information through a disgruntled or dishonest employer at a legitimate company where a card is used to purchase something, theft of mail, etc) is more likely than the loss through banking online, so the advantage of checking your accounts online more often than getting a paper statement (thereby catching fraud quicker) is outweighed by the advantage of "protecting yourself" by not banking online. It can even lead to the reduction of potential fraud elsewhere, as in the case of the elimination of paper statements and the possible loss/theft of those. So at this point I can't agree with this assessment.

What if you obscure the pattern?

[crossmr]

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 interface of some sort, using some kind of crazy method to hide the image from any kind of snooping software.

Re:What if you obscure the pattern?

[iamdrscience]

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:What if you obscure the pattern?

[crossmr]

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:What if you obscure the pattern?

[fatcop]

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/?object=A2D04F..... (mega hash number). Every different login session the image URL's for the same number different. So it appears those generated image URL's only exist for the duration of the login sequence. So only the server knows the mapping of what it sent to your real PIN. So that coupled with encrypting the out of order PIN numbers makes it even harder to crack.

I guess it doesn't really offer any more protection against a trojan taking screenshots every mouse click. I mean you're kind boned if you got that kinda trojan on your PC anyway. Its virtually like someone video taping you :) You have to have something some degree of faith in your virus/trojan protection on your PC. If you use an internet cafe you are at their mercy a bit.

It certainly seems to offer some further protection against basic data sniffing, since only the server knows the order of the PIN.

But as for "hiding the image from any kind of snooping software", if the session number image data was sniffed and mouse click positions then that's as good as a screen capture.

Re:What if you obscure the pattern?

[uhlume]

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

(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.)

Re:What if you obscure the pattern?

[iamdrscience]

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?

[fatcop]

Actually, I am using the Australian website http://ingdirect.com.au/ and it only offers keyboard entry for your client number, but for the PIN you have to use the mouse.
(And i'm using Firefox - in case that is a factor).

Re:What if you obscure the pattern?

[fatcop]

Also my other Australian bank (Westpac) ages ago switched to forcing us to use only mouse click buttons (alpha and numeric) for full password.

Re:What if you obscure the pattern?

[iamdrscience]

It looks the same in both Opera and Firefox to me, so that's not the issue. It must be that the US and Australian sites are different although that seems a bit weird.

Anyway, here's a picture of what the virtual pinpad looks like on the US site: http://itsbeenconfirmed.com/uploaded/ingkeypad.jpg

Re:What if you obscure the pattern?

[nacturation]

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.

Re:What if you obscure the pattern?

[uhlume]

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

Re:What if you obscure the pattern?

[nacturation]

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 each of those remaining 25 characters contain the new number as well. We've narrowed it down to 10 characters. Keep going with this methodology and on the third try, we're down to 4 characters. On the fourth try, that's 2 characters. And on the fifth try we should have the character. You can do this for all characters of the password simultaneously.

So, assuming the password remains the same, it will take on average five observations of the user entering the same password before you've cracked it. It doesn't matter how random, complex, or long the password is. Nor does it matter if you include all of the symbol characters as well. Five observations will get it using their system. Of course, that's better than getting it in only one observation... but not much.

Re:What if you obscure the pattern?

[nacturation]

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.

Re:What if you obscure the pattern?

[paul GridData]

Nac- The GridOne system and its patented approach allow for greater security through the use of Decoys(TM) or Decoy Digits(TM). Upon login the user simple keys in (anywhere in the actual GridCode sequence) any arbitrarily selected, extra numbers or Decoy Digits(TM) and injects them into their strand of numbers So if the real GridCode answer is 51832, the user can enter 3518932; the Decoys of a 3 and 9 are added. Now you are the attacker, and not knowing what are real and what are Decoys(TM), what is the user's underlying GridPass(TM)/password??? This extremely simple, yet highly effective security feature will confer excellent security upon login and will force the opportunistic attack to become a concerted attack requiring time, opportunity and resources. Other methods still use a broken first factor, like a reusable password or PIN, knowing that it is a weak factor or link; and it is the weak link that is attacked. Grid allows and delivers the unparalleled, proven security delivered by One Time Passwords without the need of any device, extra materials, computer modifications or time synchronization (exposed to possible reply attacks). Other methods lock the user to a machine. What if you, your employees or your customers are not at their usual machine due to travel or convenience? Having a user key in vulnerable reusable information or even worse, asking them to key in private information such as their mother's maiden name certainly is not secure. Grid allows complete portability and untethered, secure access for users who are mobile or who are not at a specific machine. Grid allows users to customize their own log-in interface to ensure they are logging into the proper site and that they are authenticating to the true GridCore(TM) server. Again, from any computer, from anywhere while raising the bar against phishing attacks. The other methods? 1 single casual observation , being shoulder-surfed or being watched as the users logs in (getting all the information and/or images), and the user's account is compromised at that instance. Ask most other authentication systems if you can "see or have everything at login" and what will their security be? Nothing is bomb-proof, but GridOne allows complete portability and untethered, secure access from any machine from anywhere, nothing to ship, mail, print, download or carry for the end users or their machines.

Re:What if you obscure the pattern?

[paul GridData]

Uh- please see my rply to "Nac", especially concerning the use of Decoy Digits(TM) upon login. "Nac- The GridOne system and its patented approach allow for greater security through the use of Decoys(TM) or Decoy Digits(TM). Upon login the user simple keys in (anywhere in the actual GridCode sequence) any arbitrarily selected, extra numbers or Decoy Digits(TM) and injects them into their strand of numbers So if the real GridCode answer is 51832, the user can enter 3518932; the Decoys of a 3 and 9 are added. Now you are the attacker, and not knowing what are real and what are Decoys(TM), what is the user's underlying GridPass(TM)/password??? This extremely simple, yet highly effective security feature will confer excellent security upon login and will force the opportunistic attack to become a concerted attack requiring time, opportunity and resources. Other methods still use a broken first factor, like a reusable password or PIN, knowing that it is a weak factor or link; and it is the weak link that is attacked. Grid allows and delivers the unparalleled, proven security delivered by One Time Passwords without the need of any device, extra materials, computer modifications or time synchronization (exposed to possible reply attacks). Other methods lock the user to a machine. What if you, your employees or your customers are not at their usual machine due to travel or convenience? Having a user key in vulnerable reusable information or even worse, asking them to key in private information such as their mother's maiden name certainly is not secure. Grid allows complete portability and untethered, secure access for users who are mobile or who are not at a specific machine. Grid allows users to customize their own log-in interface to ensure they are logging into the proper site and that they are authenticating to the true GridCore(TM) server. Again, from any computer, from anywhere while raising the bar against phishing attacks. The other methods? 1 single casual observation , being shoulder-surfed or being watched as the users logs in (getting all the information and/or images), and the user's account is compromised at that instance. Ask most other authentication systems if you can "see or have everything at login" and what will their security be? Nothing is bomb-proof, but GridOne allows complete portability and untethered, secure access from any machine from anywhere, nothing to ship, mail, print, download or carry for the end users or their machines."

Re:What if you obscure the pattern?

[nacturation]

Nac-The GridOne system and its patented approach allow for greater security through the use of Decoys(TM) or Decoy Digits(TM).Upon login the user simple keys in (anywhere in the actual GridCode sequence) any arbitrarily selected, extra numbers or Decoy Digits(TM) and injects them into their strand of numbers So if the real GridCode answer is 51832, the user can enter 3518932; the Decoys of a 3 and 9 are added. Now you are the attacker, and not knowing what are real and what are Decoys(TM), what is the user's underlying GridPass(TM)/password???That doesn't matter. Again, after observing several logins any decoy numbers will not matter. They too will be canceled out after you eliminate the possibilities. This extremely simple, yet highly effective security feature will confer excellent security upon login and will force the opportunistic attack to become a concerted attack requiring time, opportunity and resources.I agree that it is extremely simple. However, it's not that great of a security feature if the user is required to login multiple times from the same location. Grid allows and delivers the unparalleled, proven security delivered by One Time Passwords without the need of any device, extra materials, computer modifications or time synchronization (exposed to possible reply attacks).This is much better in that circumstance if you place the constraint that no other security options are available. X.509 certificates through a device, or even *real* one-time passwords would be infinitely preferable. A true one-time password is not based upon any outside information but is rather a completely randomly generated list of passwords that can be used only once. Calling your Grid system a one-time password is misleading in the general case. The problem with your implementation is that the so-called one-time password isn't random but is derived from an actual password through a simple transformation. This completely eliminates the inherent security offered by real one-time passwords. A real one-time password system is completely unbreakable even after a million observations. Your system is breakable in only five. Quite the difference. Grid allows users to customize their own log-in interface to ensure they are logging into the proper site and that they are authenticating to the true GridCore(TM) server.This is no different than any other site that uses SSL. Without SSL, your Grid system is as vulnerable to man-in-the-middle as any other one, with the exception that it takes about five observations to derive the password instead of one. Again, from any computer, from anywhere while raising the bar against phishing attacks.The other methods? 1 single casual observation , being shoulder-surfed or being watched as the users logs in (getting all the information and/or images), and the user's account is compromised at that instance. Ask most other authentication systems if you can "see or have everything at login" and what will their security be?Nothing is bomb-proof, but GridOne allows complete portability and untethered, secure access from any machine from anywhere, nothing to ship, mail, print, download or carry for the end users or their machines.If you can restrict your logins to only once per location, then I'll agree with your assertion that the security is "good enough" for casual use. However, this article concerns trojan keystroke/screencap loggers being installed on someone's computer surreptitiously. Assuming they trust their own computer, if they login from it five times in a row using your Grid system, an attacker will have compromised the password... regardless of any decoy schemes employed.

Re:What if you obscure the pattern?

[uhlume]

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 one-, two- and even three-digit key numbers (thus conferring uncertainty as to how many characters in the sequence each numeral corresponds).

Naturally, there are tradeoffs involved between security and convenience, and I'd probably want to use a system like this in conjunction with one or more additional factors, perhaps managed by a risk-based evaluation system. On the other hand, this system is easily as secure, if not more secure, than many considerably more inconvenient systems that I've evaluated, and that's worth quite a lot in the real world of online banking, where we often find it necessary to balance security with ease of use (always erring in favor of security, of course).

(In case you were wondering, I have no affiliation with GDS, nor any particular intention of deploying their GridOne system, but I do work for a financial institution which is currently in the process of evaluating a number of similar products, and their approach struck me as notably clever.)

Re:What if you obscure the pattern?

[nacturation]

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 love to do is for someone at Grid (or yourself if you have access to a live online demo) to post a challenge for me. Choose a lengthy password of any combination of letters and numbers. Then post a screenshot of the grid configuration including the numeric password you would enter. Do this, say, ten times for the same password. Upload the files somewhere, call them grid01.png to grid10.png, and I'll decode them, explaining my work, and see how many images it takes before I can guess the correct password. If I'm right, I'll only have to use up to grid05.png to decode your password. As an interesting comparison, do this both with and without decoy numbers as I'm curious how much extra complexity would be introduced by the decoys. 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 one-, two- and even three-digit key numbers (thus conferring uncertainty as to how many characters in the sequence each numeral corresponds).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). Whether multiple numbers per corner would significantly increase the difficulty of attack, I'm not sure. It'd make it more tedious to solve, but I'm not certain it would require significantly more observations. However, from their explanation it didn't appear this was a feature of the system. Naturally, there are tradeoffs involved between security and convenience, and I'd probably want to use a system like this in conjunction with one or more additional factors, perhaps managed by a risk-based evaluation system.I fully agree on that point. On the other hand, this system is easily as secure, if not more secure, than many considerably more inconvenient systems that I've evaluated, and that's worth quite a lot in the real world of online banking, where we often find it necessary to balance security with ease of use (always erring in favor of security, of course).
 
(In case you were wondering, I have no affiliation with GDS, nor any particular intention of deploying their GridOne system, but I do work for a financial institution which is currently in the process of evaluating a number of similar products, and their approach struck me as notably clever.)It's clever enough, but do the math before implementing. And again, as a solution for travelers who need to login once per location, it does provide sufficient security to make it worthwhile in combination with account timeout periods for multiple unsuccessful login attempts. But for defeating key/screen capture trojans installed on a user's home/work machine, it doesn't provide for much security.

Re:What if you obscure the pattern?

[paul GridData]

Nac, thank you for your time and thoughts. At this point you are looking at and analyzing GridOne's most BASIC GridPass (password + target corner) creation with straight substitution. I will still stack GridOne up against MOST other system and restate that other systems are compromised at first instance where GridOne is not. Regarding Decoy Digits, reductions and credible crypto-analysis has the number of necessary observations at 12+ and more than twice that depending on the underlying password complexity. Opportunistic threats are either transfered elsewhere or mitigated. Now consider a GridPass of a "password" + target corner + add 2 to that target corner. So if the user's password starts with a "G" and the target corner is a 5 the user would enter in a 7 (and so on)!!!! Now add Decoy Digits to that. The Grid system will allow users to create or use thier existing passwords, but then use various corners, combinations of corners and other "functions" that will make attack extremely difficult. Motivated user will have the ability to create GridPasses that are easy to remember, completely portable and extremely secure. And all this is with just the FIRST factor. Grid/GridOne allows the ability to completely do away with the use of reusable passwords and PINS. What percentages of ALL logins (web, domain, ATMs, VPNs, etc.) still rely on reusable information? 98+%??? Finally GridPasses can be blended or play nicely with all the other factors and schemes. And when situations require that only the first factor can be used, Grid offers superior protection. Thanks for listening and I would be more than happy to walk you through a WebEx demo to experience the full system.

Re:What if you obscure the pattern?

[Anonymous Coward]

Actually LoyalBank has a good device that makes man-in-the-middle attacks impossible.

It's a token with a keypad. To transfer funds to another account requires an authorisation key - this key is generated by your key device and requires entry of the account number, timestamp and amount into the device.

The device generates a key that can only be used for this unique transaction and thus any man in the middle attack can't use that key for anything else.

Pretty bulletproof.

Re:What if you obscure the pattern?

[nacturation]

Well, we agree on a few points. Most online sites (heck, even the bank I deal with) uses a regular password to login that, if keylogged, would be instantly compromised. Fortunately, about all they can do is pay my bills or transfer money between my accounts. Anything beyond that (eg: setting up payment/transfer to an account that isn't mine) typically involves either a phone call, where I can supply additional credentials, or a trip to the bank. So in that case, your Grid system is preferable when using untrusted computers if I go with the understanding that I shouldn't login multiple times from the same location.

In your example where you have to add a modifier (eg: 5 plus modifier of 2 = 7) I'm not convinced that increases the number of observations required. If anything, it requires up to ten times the amount of work as you need to keep track of ten variations but since each number is being offset by the same amount, you shouldn't need more samples than you otherwise would. Absent of decoy numbers, it would still require an average of five observations.

I'd be interested if you wanted to put up a challenge as I alluded to in a reply to uhlume. Setup the system with a strong password and some numeric modifier. Upload ten screenshots showing the grid configuration and the number you would have entered for each. I'll see how many images it takes for me to guess what the original password was. Then do the same but using decoy digits. Even if it turns out I can deduce the password in five attempts, it's better than having a keylogger grab the password in one observation... but I'm just curious how it would impact security. I suppose I could also use your online demo and simulate this myself, which I may do anyways... but it'd be more fun not knowing the password in advance. :)

Re:What if you obscure the pattern?

[nacturation]

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 that position. You'd have to have an average of almost 50 observations to deduce the password in that case. If this were for an online banking system, you could require a password change every three months and it would still be sufficient. Naturally, you'd want the user to have to go to their bank to change the password because if their system is keylogged then setting the password in the first place instantly compromises it.

Re:What if you obscure the pattern?

[elFisico]

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.

Hmm, but this only works once. What this basically does is to send a group of several passwords and the server then checks if one of the mapped passwords is the right one. If you can capture two different password entries with this system you just have to figure out which of the passwords in the two groups was in both groups and viola! Password hacked.

Secure banking? Yeah right.

[thedarknite]

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...

[werewolf1031]

this already posses a security problem

Round 'em up, boys! We gonna lynch us some bank robbers!

Yeah, and?

[iamdrscience]

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.

Re:Yeah, and?

[uhlume]

Most software keyloggers are trojans. What's your point?

Re:Yeah, and?

[Beryllium Sphere(tm)]

>if you've got a trojan on your computer you're going to be fucked.

A man could live for years without being handed a straight line like that one.

Re:Yeah, and?

[shigelojoe]

if you've got a trojan on your computer you're going to be fucked

I'll take "Things a computer has in common with a penis" for $1000, Alex.

Re:Yeah, and?

[shigelojoe]

I know it's been over six months since I've seen one like it.

Re:Yeah, and?

[iamdrscience]

Hardware keyloggers.

Re:Yeah, and?

[Rew190]

Not all trojans are keyloggers. All he was saying was that virtual keyboards were brought into play to defeat keyloggers specifically, not all trojans in general.

Re:Yeah, and?

[Anonymous Coward]

There's 1 hardware logger for every 100,000 software keyloggers, or something like that. Hardware keyloggers simply aren't an issue at all, it's a negligible risk. Virtual keyboards were designed to protect against all kinds of keyloggers. The idea is obviously that while it's possible to take screendumps etc., it means vastly more work, and that's another barrier for people who want to grab your password. It could be debated whether this is a sound strategy, but there hardly be any doubt that this is the intention behind virtual keyboards.

I would have thought this to be perfectly obvious, really.

just go to the bank....oh wait

[ILuvRamen]

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 have another great idea too. On the applications for web banking services, they could have an area where it says "I hereby swear that I am not a complete dumbass when it comes to passwords. It is not a. my last name, b. something I tell everyone, or c. on a sticky note on my monitor." That would get rid of at least half of the major security problems.

Virtual Keyboards are pointless

[Anonymous Coward]

The phisher justs sends an email with a link to a fake bank web site, complete with fake virtual keyboard. The duped user tries to log in while the phisher records their account and password. No need for decryption or screen captures.

Re:Virtual Keyboards are pointless

[iamdrscience]

Virtual keyboards are designed to protect against keyloggers, not phishers, and they do a pretty good job. No one technology protects all fronts of attack -- saying virtual keyboards are useless because users can still be phished is like saying that encrypting data between you and a bank is useless because it doesn't protect you from somebody looking over your shoulder.

Re:Virtual Keyboards are pointless

[Anonymous Coward]

The danger in this situation is not a man-between-client-and-server, it's a compromised client (a true man-in-the-middle). A trojaned client (software, hardware keylogger, graphical logger) is just that. There are two techniques for dealing with it:
1) classic cryptography: The human user uses Ke(M) = C, such that the trojan never sees M. That mapping would have to take place before M even reached the (untrusted!) keyboard or mouse. Usable or cryptographically secure, but not both.
2) obscurity: As someone mentioned tangentially earlier, randomly generating a computationally obscure keypad (thus a random mapping of the mouse clicks to the machine representation) would at least force the trojan (or remote recipient of its output) to perform image recognition either automatically or manually in order to recover the mapping. And that's before you prudently pubcrypted the PIN for transmission, of course. Enter the captchas,; it becomes exactly the same problem at that point. Note that biometrics and even one-time-pads would (obviously!) be defeated by a compromised client's reading the cleartext.

This application absolutely screams "public key encryption" and it's baffling that they don't use it. The whole point is that even if the attacker knows the encryption key, the system remains cryptographically secure. Gah. It's just a matter choosing to implement that instead of CLEARTEXT! Validating the PIN on the (untrusted!) client is a bad idea; it must be done on the server, or there is no secret kept by the server. Fortunately, there's a nice technological solution to this problem.

A true man-in-the-middle is an absolute bear. It is, quite literally, physical access: the ability to examine the machine's state locally, before encryption. That's not a technological problem; it's a social problem. Someone looking over your shoulder? Physical access; a social problem.

The use of cleartext just flabbergasts me. Even an incredibly unsophisticated attack can still reveal cleartext! That makes it a bigger hole to plug, and to boot it is a much easier one to plug.

Re:Virtual Keyboards are pointless

[gawdonblue]

Looking over your shoulder is exactly the problem with these virtual keyboards!

When my no-good, krusty, SOB, son-in-law borrows money he likes to watch as I transfer into his account. Before my bank made these things compulsory and I typed the PIN in with the real keyboard there was no way he could keep up as the little stars appeared on the screen. Now I have to use the mouse and as it goes around the screen and clicks on numbers they highlight and even his drug-addled brain can keep track. So now I have the choice, let him see my PIN or I can ask him to look the other way and prove how much I trust him...

In trying to protect against high-tech crime on my computer banks have just made it easier for low-life scum.

(OK, I don't really have a son-in-law, but if I did I am sure he would be a thieving scumbag and the above paranoia would be valid.)

(OK, maybe the above paranoia isn't valid, but the fact that I am paranoid is valid.)

a four digit pin??

[ampathee]

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.

Re:a four digit pin??

[iamdrscience]

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.

Re:a four digit pin??

[grahamsz]

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.

Royal Bank was down last week

[genevaroth]

The Royal Bank was down last week- they said it was "software problems" me thinks they were hacked of DDOS'ed.

No Surprise

[daeg]

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.)

Re:No Surprise

[genevaroth]

Who made that software? looks handy.

Re:No Surprise

[Vreejack]

In effect you were maintaining a one-time pad. Well, almost. A true one-time pad would be used to encrypt the entire transaction and would ideally have a key as large as the entire message, but if the point is to defeat a keylogger it is practically undefeatable.

A man-in-the-middle attack would defeat it, though, if someone could pull it off.

Re:No Surprise

[profplump]

No, it's one-time passwords, a concept which has been around for a while. http://en.wikipedia.org/wiki/One-time_password http://tools.ietf.org/html/rfc2289

It's doesn't protect against man-in-the-middle attacks, nor against phishing, but it doesn't claim to authenticate the other end either, so I don't see why you'd expect it to do so. Luckily you can combine one-time passwords with something like SSL, which can provide bi-directional authentication, to mitigate the risks of a MiM attack.

Re:No Surprise

[TilJ]

Look into any one-time password system, like OPIE or S/Key. FreeBSD has it built into the operating system, Handbook entry at http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/one-time-passwords.html.

Cut them off at the pass

[SEWilco]

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?

[zappepcs]

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.

Re:Is it just me? Am I missing something?

[zappepcs]

Yeah, I know it is supposed to be LIVE CD. Spell checking doesn't always help...

Re:Is it just me? Am I missing something?

[Anonymous Coward]

What about hardware keyoggers?

Re:Is it just me? Am I missing something?

[iamacat]

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

Re:Is it just me? Am I missing something?

[GoofyBoy]

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

Re:Is it just me? Am I missing something?

[iamacat]

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.

Re:Is it just me? Am I missing something?

[accident]

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.Too bad theres no official live CD for windows, the very group that need it the most...

Liquid Crystal Display Display

[springbox]

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.

Re:Liquid Crystal Display Display

[mackyrae]

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

[Doc Ruby]

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.

very clever

[grahamsz]

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

Re:very clever

[nacturation]

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:very clever

[uhlume]

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.

Re:very clever

[paul GridData]

Regarding brute force. Let's not confuse brute forcing a static/reusable password with a one time password (OTP). Static in NON-linear and the OTP nature of GridOne creates linear security. There is nothing to bruteforce with an OTP. Also normal account/system lock out defetas any type of guessing of automated attacks.

Re:very clever

[nacturation]

Regarding brute force. Let's not confuse brute forcing a static/reusable password with a one time password (OTP). Static in NON-linear and the OTP nature of GridOne creates linear security. There is nothing to bruteforce with an OTP. Also normal account/system lock out defetas any type of guessing of automated attacks.I agree that you can't brute-force a one-time password. However, as I pointed out in my other reply, your system is not a one-time password since each attempt is derived from a static password by elementary transformations which, over the course of observing several logins, can be trivially decoded. Once I've observed the same user logging in five times using your system, I can easily login without having to guess at the password and triggering a lockout. It's good enough if the attacker can only observe one login, but if a key/screen capture trojan is installed on the user's home or work machine for example, it offers little protection.

Never develop your own crypto protocols

[Beryllium Sphere(tm)]

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

[bonhomme_de_neige]

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/

Re:Keyring Dongle

[Aidan Steele]

Why is HSBC still the only bank doing this? Westpac also offer this, or at least for our higher-valued accounts. Nifty little toys that make me feel like a secret agent, they are. ;-)

Re:Keyring Dongle

[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 transfer, respond with error/success/whatever message)
the only way I see to make a secure system is to have a secure endpoint = hardware device that treats the client computer as just another hop in the unsafe internet cloud

Re:Keyring Dongle

[Wormholio]

Why is HSBC still the only bank doing this?

They don't seem to be doing it in the US. HSBC here have just added the virtual keyboard to their site. At the same time I was setting that up I was also forced to change my password, becasue the old one contained special characters and the new policy only allows letters and digits. So that didn't inspire much confidence in their new extra layers of security. Even worse, I think, is that their site fails to function at all if you turn scripting off, so it's ripe and ready for the next JavaScript exploit. I would put more trust in a simple https connection without scripting, using the external cryptocard/dongle.

But they are not the worst. This summer I helped my father learn how to use online banking for US Bank, and found that they have a username/password entry form right on their non-SSL home page . So I had to try to explain to him why not to use it, which was difficult given that they put it right there and he's inclined to trust his own bank.

Re:Keyring Dongle

[enbody]

Someone mod this guy up.
It's called a man-in-the-middle attack, and it works nicely in this situation.

Re:Keyring Dongle

[Anonymous Coward]

Unfortunately, phishers appear to be having a field day with such passwords too. I'd rather have an offline authentication code - something that is sent to my mobile via SMS, directly by the bank, without touching the internet, and having me enter it separately after logging into the bank's website. Phishers can intercept this code too - but if the code is tied to the transaction details - value, beneficiary etc, the customer would not enter this into the site when he sees a large transfer to a phisher (hopefully).

Re:Keyring Dongle

[statusbar]

While what usbank.com is confusing to users, if you look at the source code for the non-ssl page you can see it actually uses SSL to transmit the information.

--jeffk++

Have a split PIN system

[caluml]

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).

Re:Have a split PIN system

[aussie_a]

I don't have a cell phone but I do have a bank account. How am I suppose to use this?

Re:Have a split PIN system

[Anonymous Coward]

Make that 5 minutes, and one use only. If the code that was texted was entered correctly (even if the regular PIN half wasn't) it should be consumed. Other than that, a clever idea that I'd be happy to use.

PINN?

[DaTrueDave]

Must they refer to Personal Identification Number numbers?

Re:PINN?

[MLease]

You know that if they started calling them PINNs, they'd start referring to them as PINN numbers, and then they'd have to start calling them PINNNs. And the day when PINNNNNNNNNNNNNNNNNNNNNNNNs appear wouldn't be far behind.

Maybe we should just call them PI numbers to spare ourselves that...?

-Mike

phishing happens because the banks don't care

[thogard]

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 more than 3 months if they couldn't take credit card payments.

There is a simple solution to the problem and the infrastructure already exists. I know this because I used to work directly or indirectly with both card schemes.
(if your from a bank reading this, get in touch with me and I can provide details on how you can push this, just follow the links or google for my name and you will find links to contact me)

Solutions to stop phishing & trojans etc

[jonwil]

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.

Re:Solutions to stop phishing & trojans etc

[m94mni]

I've had such a device, when I had an account in the Swedish bank Swedbank. Works pretty well, but much less convenient than the certificate-based solution I use now in Skandiabanken.

Re:Solutions to stop phishing & trojans etc

[BenjyD]

That's basically what my bank does, I have a little keyfob thing that generates an access code every time you press the button.

pins aren't supposed to be passwords

[Joseph_Daniel_Zukige]

Institutions that use them as passwords ought to be liable for the resultant misuse, and I guess many of them have pretty much decided the liability is cheaper than implementing the proper use.

It occurs to me that, with money this loose, basing the economy on money makes less and less sense.

Probably, the best solution is to return to making everyone grow their own food, and giving up trying to manage value through banks and financial regulation.

Banks and third-party Javascript

[timlewis_atlanta]

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 ?

Re:Banks and third-party Javascript

[Anonymous Coward]

I'm not 100% positive, but I believe that liveperson is a support service that allows companies to provide real time 24/7 live chat (support) to their customers.

Boot from CD ROM

[2901]

I don't get why banks are trying to do money stuff with a domestic grade operating system.

I would expect to collect a CD ROM in person from the Bank. Then I would do my internet banking by booting my machine from the Bank's CD ROM, connecting to my bank account with a client program that was on the CD and runs on the bare metal.

Re:Keyring Dongle - RSA SecurID

[Anonymous Coward]

RSA has had this type of product available for quite sometime now.

It will integrate into Cisco VPN solutions, things that support RADIUS, and I am pretty sure they have some SDK's to integrate it with pretty much anything you are trying to do..

http://en.wikipedia.org/wiki/Securid

http://www.rsasecurity.com/node.asp?id=1156

Cheers!

There is a simple solution, the One Time Pad

[Dan B.]

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 electronic OTP, and each six-digit number is good for one login attempt, one payment or one transfer only. And that's the beauty of an OTP. You can't predict the next number, and the number just used has been used for ever.

Now I do understand that there must be some algorithm to match the number off my pad and what the on-line system is expecting, but I have my doubts as to whether or not that could be broken by a man-in-the-middle or a key logger attack.