30

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?

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
Zenon
  • 402
  • 4
  • 6
  • 6
    I've seen this with a full virtual keyboard on the screen with the instructions to move the mouse into the key from a specified direction and move it back out in a specified direction to "click" that key. The attacker only needs to become aware of this and add code to figure out the instruction text (next they put the instructions in an embedded video, shuffle the keyboard each time). The attacker will adapt to this next week. – Skaperen Jan 27 '13 at 06:06
  • Banks are now using two phase mechanism like they send a one time password to mobile which needs to be entered to authenticate. – Neil Mar 22 '13 at 07:50
  • @Neil not all banks do that. And although it would be a more secure way, I am convinced, I dread that day since I will have to buy a cellphone. I want security tokens. – Zenon Mar 22 '13 at 12:58
  • 1
    http://security.stackexchange.com/q/22774/971, http://security.stackexchange.com/q/152128/971 – D.W. Feb 24 '17 at 11:58

3 Answers3

55

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.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Pretty nice summation! – Leniel Maccaferri Jan 27 '13 at 02:18
  • 20
    hovering will not work on tablets / touch devices, which will be an increasing percentage of the computing devices in the world every year from now on. – Jeff Atwood Jan 27 '13 at 02:58
  • 1
    Seems like a ridiculous race. The danger of keylogging can be averted by using a one-time password generated by hardware tokens. Even if the one-time password is compromised, it would have immediately expired and be useful for nothing. – Lie Ryan Jan 27 '13 at 03:33
  • @LieRyan If the device is compromised, there is no guarantee. Even if a password is not compromised, there is a valid session that can be misused directly. – curiousguy Jan 30 '13 at 00:42
  • @curiousguy: If the device is compromised, the bank can simply issue a new device with a new seed, compared to changing PINs/password it's obvious which is more secure. And the danger of compromising an active session always exists whatever auth method you use, so what's your point? Anyways, many banks that use token authentication requires new password for every transactions, a single-use password is valid for one transaction only and is time-limited or use a challenge-response so the password is only valid for that particular transaction. Some also SMS/email you your transaction receipt. – Lie Ryan Jan 30 '13 at 08:33
  • @LieRyan "_If the device is compromised, the bank can simply issue a new device with a new seed_" I mean if the device you use to connect "securely" to your bank. "_And the danger of compromising an active session always exists whatever auth method you use, so what's your point?_" My point is that a compromise of your computer is probably the most likely practical threat. – curiousguy Feb 01 '13 at 00:19
  • @curiousguy: security token is usually offline, so compromising them requires physical possession of the token, and just like PKI systems, it doesn't really matter if an attacker figured out how the device works, because what matters is the secret private key which cannot be easily extracted from the device even with physical possession of the token. – Lie Ryan Feb 02 '13 at 07:49
  • @curiousguy: I agree though that compromising the computer is a more likely event than compromising the token. However with challenge-response and second device receipt, it would be extremely difficult to forge transactions, and nearly impossible to do so without being immediately noticed, even when using a compromised computer. – Lie Ryan Feb 02 '13 at 07:55
  • I read a few times that key loggers don't record what keys you press but what characters are to be entered by os. On screen keyboards generate same input and are just as vulnerable. The situation you described seems contrary to that notion, is what I read wrong? – user5948022 Apr 07 '16 at 18:20
15

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!

Community
  • 1
TildalWave
  • 10,801
  • 11
  • 45
  • 84
  • Thanks for this answer, I didn't knew about that 'bug' (feature? :) ). – Zenon Jan 26 '13 at 23:24
  • 4
    You're welcome! I thought I should mention this as it wasn't mentioned in an otherwise excellent response by @Thomas Pornin. Additionally, it's uncommon to attribute a status of a 'feature' to a bug from Redmond. That's more commonly reserved for a certain Cupertino based company. They have quite possibly patented it as well LOL (just a joke) – TildalWave Jan 26 '13 at 23:42
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!).

Community
  • 1
culix
  • 164
  • 1
  • 12
  • 2
    But two factors auth does not protect your session. – curiousguy Jan 30 '13 at 00:43
  • @curiousguy Two-factor authentication does not protect your session, no. But neither does using a virtual numeric keyboard. 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. Does that make sense? I will update my answer. – culix Feb 10 '13 at 06:50
  • It would be better if they also send you a one time code before any transaction (the code being valid only for the particular transaction of course) – resistor Feb 10 '13 at 10:40
  • @resistor I agree. Maybe if the arms race continues to escalate as Thomas describes banks will eventually start to do that? – culix Feb 10 '13 at 22:50
  • @culix "_Does that make sense?_" It does. But how do you know you have logged out? – curiousguy Mar 06 '13 at 02:55