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.