Does overlaying the mouse on a virtual numeric keyboard really protect against keyloggers?

Question

I just saw for the first time a new way to enter a password, at the Banque Postale (French Bank). You are given a virtual numeric keyboard and to type you can just leave the mouse cursor over a number for what seems like 1 second for it to be entered.

At first this seems pretty nice, you don't have keyboard strokes to record, nor mouse clicks. Yet, I have the uncanny impression that there might be a problem with this system. The obvious one is that you are only allowed to put numbers in your password, would there be anything else?

Answer 1

These kinds of password entry systems are only good as long as the attackers do not adapt. It is a play in several acts:

1. Bank Web sites use passwords which are entered the traditional way, with a keyboard.
2. Key loggers appear, and harvest key strokes.
3. After some cases of actual bank password theft, banks adapt. They implement "visual keyboards" in which the user clicks on some buttons which are labeled with letters or digits.
4. After some time, attackers adapt. New-generation key loggers also record mouse click coordinates. These coordinates are sufficient to recompute the password.
5. After some time, banks adapt. They now "shuffle" the labeled buttons so that they do not always show up on the same emplacement on the screen. Mouse click coordinates are no longer sufficient to recompute the password.
6. After some time, attackers adapt. Next generation key loggers now take local screen shots, recording the pixels which are around the point where the user clicked. The screen shots are sufficient to recompute the password.
7. After some time, banks adapt. Instead of clicks, the bank's Web site will react to some "hovering" without an actual click. The current key logger generation does not record "hovering", only clicks, so they are defeated.

As you observe, we are currently at that point. Can you guess what is going to happen ?

---

This is an arms race. The attackers force the banks to apply more convoluted password entry methods. The banks train attackers into defeating increasingly "secure" password entry methods. Simultaneously, banks try to train their customers into dealing with more complex password entry methods. In the long term, my bet is that attackers will evolve faster than customers; the banks fight a losing battle.

Answer 2

Such protection mechanism you're describing could possibly be exploited by the IE mouse tracking flaw, an Internet Explorer vulnerability that allows an attacker to track your mouse cursor anywhere on the screen, even if the browser is not being actively used, and to me seems such password protection would be more at risk of being compromised than your average run-of-the-mill solutions involving keyboard input, as it wouldn't even require of attackers to hack their way into end user's machine and install a key logger.

All it would take is for exploiters to hide an IE window (easy enough, say a pop-under would make most users unaware of it), or displaying third-party advert that's running a script recording mouse movements. Without wanting to give away too much information on how such exploits could be made to work (for obvious reasons), suffice it say mouse movement patterns can be matched against a use of a keypad like the one posted in your example, especially since the user is first required to click on a statically positioned access button and the keypad positions relative to the window (centered horizontally and vertically), through which the keypad's absolute position can be easily calculated.

Simply tracking mouse movement alone can as well, that's true for most users, tell you when a mouse button was clicked. But even without tracking mouse clicks, recording mouse movement alone can be enough to calculate if a user is indeed logging into a mentioned bank's account, and use subsequent mouse movement to calculate what his/her PIN was.

To cut things short, my 2 cents: I would advise against such mechanisms until ALL user agents (browsers) accessing it are considered secure enough in regard to it's function. ;)

UPDATE: Developer has by now updated the keypad display code and its layout is now randomized. Individual keys are shuffled between each other, which of course effectively prevents this particular exploit that I've mentioned, by using external browser window JavaScript alone.

It is still far from being a perfect solution and is not safe, not even by a long shot;

Keys are dynamically drawn through an external CGI application and identified by URI parameter string and a unique session key stored in a cookie, however they're accessible through this same URL address even when request fields change, e.g. have no referrer and are opened directly. They only appear to be sensitive to a session cookie value, and maybe user-agent string, but I haven't checked for the latter as -

It does not even matter:

A single malicious browser plug-in could easily read user's input by tracking mouse movement, mouse clicks, and reading glyph URLs used (or attaching glyphs themselves in a POST response) and send all this information to an external or remote processor. The entered PIN itself is also stored in plain text in a hidden form field (conveniently named password) which makes it even easier to retrieve its value through a simple JavaScript call than if a build-in password field type would be used. This fact is hidden from a normal user by displaying meaningless bullet glyphs in a display box below the keypad. Who is that supposed to fool? It took me less than 5 seconds to find a relevant hidden field, and I'm not even a security analyst! It would take me additional 15 seconds to write those 2 lines of JavaScript to read it and send to a remote location.

So there we have it:

A lot of work has gone into make believe and cheaply buying end-user's false sense of security, while at the same time this very same end-user has gained absolutely nothing. Both versions (previous static, and the new shuffled layout) effectively prevent simple keyloggers merely doing what their name suggest - logging keystrokes (well done for getting the meaning this one!), but the layout randomization does nothing to prevent a plethora of other JavaScript/browser plug-in exploits. And under certain conditions the user's entered PIN (especially such a low hanging fruit as one stored in clear-text) can be read by malware, even if browser and OS are doing their best to prevent this. Certain browsers would, of course, be a lot easier to exploit and read active memory data from than what's described in that answer, but I wanted a strong case against storing clear-text passwords in memory.

Conclusion:

Storing passwords/PINs in clear-text in a hidden form field and employing loads of JavaScript obfuscation trickery simply isn't what any bank should be considering as a safe mechanism, and in the end fools no one that it's any safer, except possibly the very same ones it's supposed to protect. Oh, and obviously also whoever it was that approved these changes, their developer(s), and pretty much anyone else working in the mentioned bank.

Dear Banque Postale, for the sake of your clients and your future existence, please stop with these lame attempts at reinventing the wheel and hire a proper IT security expert!

Answer 3

As Thomas mentions, different forms of password entry will only protect your password until the forms of attack evolve.

A stronger protection against keyloggers would be to use two-factor authentication and ask for a different type of authorization on another channel. For example, the bank could send a one-time code to your phone, and only let you log in if you provide both your regular password and the one-time code. Each time you log in they text you a new code to make sure that the person logging in really does have your phone.

Protecting against keyloggers and other compromises to your computer is difficult. Two-factor authentication ensures that even though your keys are being logged the attacker cannot compromise your account once you log out. They are only able to perform an attack while your session is active, which is a much smaller window. Knowing only your password does the attacker no good, as they still need the codes sent to your cell phone.

Using two-factor authentication means that as the types of password attack evolve your account is still safe, and only you can log in (assuming, of course, you keep control of your phone and notify your bank if it is lost or stolen!).