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

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?

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

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.

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.

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.

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

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/

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.

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 ?