Is the option to jump to blanks in password fields a security risk?

Question

Using Ctrl + ← / →, it's a common behavior across different operating systems to jump from word to word (or from blank to blank) in text input fields.

Now I've discovered that this also applies on password fields in Internet Explorer 8 and 11 (I haven't tried it on other versions yet): the actual text is masked with bullet points, nevertheless I'm able to find blanks using the mentioned keyboard combination.

At least in Chrome 38, the combination only jumps between the beginning and the end of the whole text.

• Why isn't this fixed in Internet Explorer?
• Can this be considered as a security risk? It's only relevant if the password is stored; I guess, this opens more serious attack vectors using external tools, like reading the password from the password store, or using unmasking tools. Still, doing the word jumping, it's possible to get a quick idea of the password using Internet Explorer's built-in "features"
• Is it possible to change the word delimiter (a whitespace?) at runtime? So could I change it to 'a', and jump to every 'a' using the arrow keys?
• As mentioned in the comments, it's also possible to jump to special characters like $, although here the cursor would stop both before and after the character. Is the exact "jumping algorithm" documented anywhere?
• Are there any other problems with the described behavior of Internet Explorer?

Answer 1

No that is not a security risk.

Having stored passwords in a browser is a security risk. Letting an attacker access your computer between when you've typed in the password and before it is submitted is a security risk (and even after you've submitted it, you need to worry about theft of valid session cookies). Being able to jump to blanks/special characters in a typed in password is not a risk.

After a password has been typed in the password field, its in the browsers DOM and only takes the least bit of effort to extract the full value out from it. E.g., if you go to the developer's javascript console (e.g., in chrome/linux type Ctrl-Shift-J) and type in (you can skip the comment lines that begin with //):

var inputs = document.getElementsByTagName('input');
// find all <input> elements in the page

for ( var i = 0; i < inputs.length; i++) {  
// loop through all <input> elements

    if (inputs[i].getAttribute('type') === 'password') {  
    // find input elements with attribute type="password"

        console.log(inputs[i].value);
        // print the values of these password elements to the screen.
    }
}

It will print to the screen whatever text is typed into any password fields. (This code is equivalent to the jQuery $('input[type=password]').value, which will work if the webpage has loaded jQuery).

You could just type the word javascript: in the location bar and then paste

var inputs=document.getElementsByTagName('input'); for( var i=0; i < inputs.length; i++ ) { if (inputs[i].getAttribute('type') === 'password') alert(inputs[i].value) } 

into the location bar and whatever text is in any password field will be alerted to you. (Note most browsers will remove the javascript: part if you try to paste the full URL, so you will have to type it.

javascript:var inputs=document.getElementsByTagName('input'); for( var i=0; i < inputs.length; i++ ) { if (inputs[i].getAttribute('type') === 'password') alert(inputs[i].value) }

Answer 2

Yes, is a security risk, but exploiting it is very unlikely.

It can be exploited this way:

1. Someone uses your computer without you around

2. Have enough time to open IE

3. Connects to a website with a saved password

4. Gets the profile of your password and goes away

If the intruder have enough time to do all the above, it would be way faster and simpler to download a keylogger, install it, give all the permissions on firewall, have the antivirus ignoring it, and leave.

So, if you are thinking about the password profile, you have more serious problems to think about.

Answer 3

The password is not displayed on screen to avoid shoulder-surfing attacks but it is still of course known to the browser. When you use a password store, it gives the actual password to a requesting application and not a hash or encrypted version of it (that'd be very untractable to use).

If someone is close enough to you that they can use your keyboard to see whether you typed words or not then they are close enough to shoulder surf your keystrokes and your password's security is already compromised.

Answer 4

Security risk? You're leaking data, so yes it is definitely a security risk.

But risk is the chance of it happening times the impact. The chance is low because it's not every day that you are typing in a password and then leave before logging in. The impact is also low because it's often much easier to just reveal the field's value (especially in browsers) and even if not, you'll learn only the position of whitespace. That still leaves a lot of options when cracking the password.

So does it matter? No, not really.

Answer 5

It's unfortunate, of course, but when the intruder is already able to impersonate you (because you forgot to lock your workstation) than he'll in principle be able to access IE's memory and read the password directly. In practice you would use a tool for this. I once, as a test, successfully read back my own password using the browser's developer tools. No need for control+arrow and brute-forcing the pieces.

It would be bad if this vulnerability would be present in the Windows log-on screen, because it would make correct-horse style passwords significantly less secure. However, on the log-on screen control+arrow jumps to the start or end of the text box.

Answer 6

In many cases, an attacker with physical access to the computer could also go into the browser's settings, view the list of saved passwords, and hit Show Passwords and view all of the saved passwords right there. Since physical access to the computer is required for this as well, the ability to view saved passwords is much more of a threat.

Answer 7

In any instance of a vulnerability, adversarial thinking helps. In what scenario would I find this vulnerability helpful, if I maliciously wanted access to someone's account?

Well, as a sysadmin, I have access to everyone's password hash, along with any salt and pepper. But, because they are hashes, I still cannot crack a password which is well chosen. I am not the only sysadmin, so I cannot install tools to password snoop and guarantee that they will not be detected.

But the user has typed in their password, and left it with asterisks there. If they have walked away from the computer, while leaving themselves logged in, there are any number of things I can do to recover the password. But they have not. They have, instead, called me over to help with a problem they are having with their browser, keyboard, mouse, whatever.

Under the guise of testing, I can click around, click their username, select text on the page, hit tab, the password field is selected, ctrl and the cursors... or I can log in myself, type my username into the name field, click on the end of the password field, move my cursor to the beginning in a natural-seeming way...

...a fraction of a second, and I've established that their password is of the form "aaaa??aa", and my task of cracking their hash has become vastly easier, because I only need to test that pattern space. Assuming they could use any character on a keyboard, my problem space has reduced from 94^8 = 6*10^15 possibilities, to merely 62^4*62^2*32^2 = 5*10^13.

Which is already a hundredfold improvement, which allows a much wider range of attack patterns; but more importantly, I can tailor my attack to try things which are likely to work first: all four letter words from my dictionaries; then two arbitrary special characters, likely a repeat, or a punct and space; then two characters, most likely numbers, especially if we require numbers in our password policy.

So yeah - it can be done in their face by a support tech, and leaves no trace that a skilled user or other support techs might discover, such as those left by keyloggers or rootkits.

[Edit: I just realized there's also the possibility of it being "????xx??" with that pattern - but that is only 32^6*62^2 = 2*10^12, within possibility for brute forcing.]

[Edit2: I picked xxxx..xx as an example of where it would be good to know, but let's consider the worst case 8-character pass: xxxxxxxx. That's dropped the attack profile from 94^8 to 32^8+62^8, or 2*10^14, which is still a 30-fold reduction. Longer passwords give better reductions, of course, but are still harder to crack. But not only that, I will be able to strip a whole load of rulesets from my attack profile, so if the password is in any way non-random, I'll hit it that much earlier.]