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?
  • 4
    Note that it will also jump to special characters, not just blanks. e.g. 123$456 will make it jump to the '$', these can be found out as the cursor will stop in front off and behind the char, unlike the space where it will only stop once.
    – BadSkillz
    Commented Oct 16, 2014 at 11:24
  • 2
    @BadSkillz Love it - using different (stored) passwords, thanks to IE, I'm able to distinguish them now based on the position of blanks and special characters \o/
    – stuXnet
    Commented Oct 16, 2014 at 11:26
  • 6
    I haven't tried IE but I just tried Firefox's built-in dev tools (F12) and Network->Params dumps the submitted form parameters in plaintext. Including the password.
    – Zan Lynx
    Commented Oct 16, 2014 at 23:33
  • 6
    I tried IE 11 and its developer tools also dump password fields in plain text. In other words, you have more serious problems to worry about than where the spaces are.
    – Zan Lynx
    Commented Oct 16, 2014 at 23:55
  • 2
    @KnightOfNi nope, it wouldn't take over 2 million seconds to brute force it. In kasperd's scenario, you can just swap one character of the whole masked password and get feedback if it was correct. If it was, you can continue with the next character. So, given a length of 8 and only letters, it's 52 * 8 instead of 52 ^ 8.
    – stuXnet
    Commented Oct 18, 2014 at 20:09

7 Answers 7


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"

        // 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) }
  • 1
    Yes, of course, there are many bigger risks when someone is jumping from blank to blank on my computer, I totally agree. But it's still another (easy and quick) way to get information about the password, isn't it? Why wouldn't you consider getting (very basic) information about the pw as a (small) security risk?
    – stuXnet
    Commented Oct 16, 2014 at 17:55
  • I'm just not sure for myself if I would call it so, that's why I'm asking.
    – stuXnet
    Commented Oct 16, 2014 at 17:56
  • 1
    @stuXnet - Can you think of a scenario where this could gain any info about the password via this attack, where you couldn't recover the complete password via javascript:var inputs=document.getElementsByTagName('input'); for( var i=0; i < inputs.length; i++ ) { if (inputs[i].getAttribute('type') === 'password') alert(inputs[i].value) }? As an analogy, having the last 4 digits of your credit card # on your receipt stored by a business isn't a security risk, as you just handed your full credit card (with your name, the full number, exp date, CVV, etc) to the person who swiped it.
    – dr jimbob
    Commented Oct 16, 2014 at 18:07
  • 3
    @stuXnet The flaw in that scenario is giving her any access to your computer while the password is typed in. A good password will have some ~60+ bits of entropy (to prevent the hash from being cracked offline); knowledge of a few spaces/special characters reduces it by maybe a dozen bits, but out of the realm of an online attack. If she can secretly find the spaces in the password field, she could say accidentally erase/alter it and force you to retype it (and gain more information by watching you type). Or she gets a confederate to come distract you for a second.
    – dr jimbob
    Commented Oct 16, 2014 at 18:24
  • 3
    @drjimbob: I think that in many cases, from the moment someone achieves physical access to a machine, most security defenses will collapse: people store passwords, files, ssh keys,... on their machines without any encryption. Even if your machine has a password, it can be bypassed by running a live Linux distribution... Commented Oct 17, 2014 at 0:51

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.

  • 10
    I think this is not a good example, since installing a keylogger usually requires more privileges then using an open webbrowser. It also leaves potential traces and may be catched by various software and providing low deniability in case you are catched. This is a whole different vector! But running IE developer tools, or pastin JS in the adressbar is rather low-profile and still gives you the whole PW with little effort
    – Falco
    Commented Oct 17, 2014 at 8:48
  • 7
    Really, if somebody gets your computer and you have a saved password the 'hacker' could use developer tools in any browser to change the input field from password to text. What I'm trying to say is that if somebody is savvy enough and has your computer, this security risk of CTRL ← doesn't really matter. Commented Oct 17, 2014 at 13:37
  • 1
    Installing a userland keylogger does not need much more privileges than opening the browser, and the majority of users will log on with admin privileges anyway. As @Howdy_McGee said, if one knows how to open the Dev Console, s/he will know enough to hide anything done.
    – ThoriumBR
    Commented Oct 17, 2014 at 13:59
  • This is a security risk for saving passwords, not for being able to jump to blanks.
    – user21287
    Commented Oct 26, 2014 at 8:23

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.

  • 3
    If someone is able to get to my keyboard and open IE, where I have all my passwords stored, there are tons of security risks, yes. Scenario: I'm asking a colleague to help me with our intern business application. She opens the browser, and log in using the stored password. If she's fast enough, it wouldn't be hard for her to find blanks in my password, without me noticing.
    – stuXnet
    Commented Oct 16, 2014 at 11:58
  • I'm not sure if you understood my question correctly: It's not about them shoulder surfing / seeing me typing words, it's about them seeing a stored password (this sounds paranoid, doesn't it?) and being able to make some kind of a profile solely based on Internet Explorer's built-in "features".
    – stuXnet
    Commented Oct 16, 2014 at 17:15
  • 1
    The first paragraph was to make sure you knew about apps being able to pull out the password in clear text (i.e., it's not a bug it's a feature). The second paragraph was my answer: I couldn't think of a reason why this feature would be a security risk significantly higher than what you'd be exposed to given the threat model that makes it exploitable. This being said I must say your attack scenario does sound realistic enough and we'd probably be better off without that feature in IE. Commented Oct 16, 2014 at 17:25
  • 3
    @stuXnet: Seeing a stored password, but IE is only displaying dots on the screen? What a pity, hit F12 (devtools) and view the password input value in plaintext.
    – Bergi
    Commented Oct 17, 2014 at 5:44

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.


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.

  • The Windows 8.1 login screen clears the entered password after 30 seconds of inactivity, so it wouldn't be much risk even if control+arrow did work. But +1 anyway. Commented Oct 18, 2014 at 17:03

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.


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .