I’m going to have to disagree with Bruce Schneier and Jakob Nielson on this one:

I, and many other users, are often in situations where we are in the position of logging into systems in the vicinity of people with which we wouldn’t want to share the password.

Let’s look at the arguments against masking from the original story:

  • Users make more errors when they can’t see what they’re typing while filling in a form. They therefore feel less confident. This double degradation of the user experience means that people are more likely to give up and never log in to your site at all, leading to lost business. (Or, in the case of intranets, increased support calls.)
  • The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security.

I’m not sure I agree with the first one at all.  Password entry is so commonplace now that only the freshest of the new users would decide to not use a site or product because it masks passwords.  Everybody has experience with it and knows what they’re getting into.

As far as overly simple passwords go, I think that the need to remember the password is the limiting factor here, not having to type it blind.  If you displayed the password back to the user as they typed it, I don’t think most users would choose any more complex passwords than they already have.  Copying and pasting passwords is actually a great idea here, but not quite like Jakob Nielson has put it.  If you have a password manager, like KeePass X, copy a masked password from there into a masked field, and it falls out of your copy buffer afterwards, you’ve got pretty good security even when someone is looking over your shoulder.  They could catch your password to unlock your manager, but looking over someone’s shoulder at the keyboard is magnitudes of order more difficult than reading a password off a screen, especially if the user can type it quickly (being one of the few passwords they actually have to remember).  Even if they do, that password won’t get them into a remote system, they’d have to get ahold of your password management db first.

The checkbox idea is alright, though:

Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.

I think more users would be at risk, more often than they think, if password fields were unmasked by default.  I would support having a checkbox like this checked by default in all situations.  Then a user will have to at least think for a moment and maybe assess their current situation before deciding to unmask.

If people start implementing non-masked fields because of this, I’m investing in a higher resolution camera with a good zoom.

Moyix made a really great point on twitter in response to this:

@McGrewSecurity Makes attacks like http://crypto.m2ci.org/unruh/publications/backes08compromising.html much more effective too :)

The link goes to a very interesting paper on reading data off LCD screens from the reflections on objects in the vicinity.  Not to put words in his mouth, but Bruce would, if he ever read this blog, likely argue that this is a movie-plot threat, but it looks pretty doable to me (and a fun project).

Moyix’s blog, “Push The Red Button” looks very nice too.  I’m definitely adding it to my reader.

  5 Responses to “Password Masking”

  1. I agree. Also, if I see a website or application with an unmasked password, then I also assume that the people that created it have a lower level of security awareness. If it’s unmasked to the user, then it’s probably plaintext in a database somewhere too. I would probably end up using a less secure password and use the same one for every website/application. Same goes for websites/apps that email passwords in plaintext.

  2. Don’t be so quick to throw this to the wayside. Perhaps we should employee the G1′s technique, and mask characters after a second of them being visible. Once you begin typing a subsequent character, it is masked. This allows people to see that they may have mistyped a character. It may further aide HCI without dramatically reducing security.

    • The iPhone OS that runs on my iPod Touch and my wife’s iPhone does that, and I really think it’s great for a device where you’re likely to make typing errors, and small enough to easily move around and shield from prying eyes.

      When implemented on a larger, stationary scree, though, I’m not sure if it’s much more secure than just showing the password unmasked. Anyone watching over-the-shoulder or with some camera rig as described above could catch the password easily, without the user having the recourse of being able to move or shield the display.

  3. Barnes & Noble AT&T Wifi access pages feature a non-masked password entry. I admit every time I type that in I feel like I’m pulling down my pants, standing up, and waddling around while the login processes. I hate it.

    I saw thsi fly through the pauldotcom mailing list last week, and I’d restate one of my points about an unmasked password, depending on the circumstances: We lose the ability to effectively know no one else saw the password.

    It’s tough to watch someone type a password and be able to reproduce it. But it is not tough to get the briefest of glimpses of a password and be able to reproduce it. Especially when so many passwords are, at their base, a word or easy phrase with a few char subs and/or numbers/non-alphas behind them.

    I also am in regular position to see and be seen typing in my passwords.

  4. I forgot to add that this is one of those grumpy-sounding posts by Schneier. A “get off my lawn!” sort of moment.

    If we really want to get this ornery, then we should see a companion case against regular password changing/expiring because that degrades a customer experience when they forget they changed it yesterday and have to increase support calls to work the issue out.

    All in all, a useful discussion, but some things just don’t need to be changed, really. :) The risk savings is low if not actually in the red…and the real risk of elaborate setups like reflections is admittedly exceedingly low for most. :)

 Leave a Reply



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2012 McGrew Security Suffusion theme by Sayontan Sinha