Nielsen, Password Masking, and the iPhone

This is my reaction to the recent password masking debate Nielsen ignited. Summary: A checkbox to show the password is acceptable (perhaps ideal), but showing passwords by default or using the iPhone-style solution on websites is a bad idea.

Introduction

Recently, respected and influencial usability guru Jakob Nielsen stated that "[u]sability suffers when users type in passwords and the only feedback they get is a row of bullets," which "doesn't even increase security, but it does cost you business due to login failures." This is probably one of his most popular recent alertboxes due to its very controversial nature. Most of the reactions I have heard have been very negative, as Nielsen ridiculously dismisses out-of-hand the potential for shoulder surfers to oversee passwords ("a truly skilled criminal can simply look at the keyboard and note which keys are being pressed"). That is, of course, rather naïve. Why not say, "A truly skilled criminal would add a keystroke logger," or "A really determined bastard could waterboard victims for passwords."

His final suggestion is to stop masking passwords but to provide a checkbox to enable masking, if so desired, in cases of high security (e.g. bank websites). I find this completely unacceptable for reasons Nielsen himself has enumerated in other contexts.

Regardless, Nielsen does make some good points in his alertbox.

Constraints, concerns, and observations

1. Nielsen: Being able to view your password instils a sense of confidence and allows the user to ensure they entered it correctly.

2. Nielsen: Users spend most of their time on other websites.

3. Those who can't touch-type have more trouble with passwords then those who can (assumed by myself; should be self-evident).

4. Nielsen: Users skim, and they read in an F-pattern.

5. Nielsen: Users have a harder time entering passwords confidently on mobile devices.

6. Nielsen: ...but it's still not easy on desktops and laptops.

7. Good mobile devices deal with observation 5 (e.g. iPhone).

All masking, all the time

Pro: Eliminates shoulder surfing.

Con: Doesn't allow users to check they entered the password correctly.

iPhone style password masking

This is the style popularized by the iPhone, though they probably did not invent it. As Gruber succintly put it:

The iPhone strikes an interesting middle ground here -- it shows you each letter you’ve typed in a password field for a second or so before turning it into a bullet.

At most one character is revealed at a time. This applies not just for iPhone apps but also for web pages viewed in Mobile Safari.

Some have made attempts to implement this on websites with JavaScript hackery. I think this is an absolutely horrible idea, though innocently conceived. Go ahead, though, try it out if you aren't familiar with the iPhone.

If Apple thought iPhone-style password masking were ideal for the desktop, as well as for the iPhone, they would implement it on the desktop. They do not.

• If someone types fast enough shoulder surfers cannot see the password, then they are typing too fast to get the benefit of confidence that Nielsen described.
• If someone types slow enough to get the benefit of confidence, then they are typing slow enough for shoulder surfers to catch the password.

The implementation would be extremely difficult to get right on the Web. I have not seen, and (since the above items make this solution less than ideal anyway) do not expect to see, an implementation that gets it right. A solution would need to prevent plaintext passwords from being shown when JS is off and in all browsers. It should also allow editing a password from the middle, because that's how it works on the iPhone and in normal password boxes. Those of us with lots of HTML experience can imagine how very difficult that would be to implement. It should not break "wand" or auto-fill browser functionality. Also, going "back" a page in (any and all!) browsers should not show a plaintext password.

Lastly, in the case that browser and/or operating system manufacturers change the way password boxes work (say, with a built-in toggle mode, or iPhone-style on mobile devices), JavaScript methods like this will override that and possible break the password box completely for those users.

Verdict: a bad idea in theory as well as in practice.

Providing a checkbox to enable masking (masking off by default)

Thinking about observations 2, 3, and 4 from above means that any websites with password masking off by default -- even if they have a checkbox to enable it -- can and will catch users off-guard; some will enter their password before realizing it wasn't masked. It will be seen. It is irresponsible to pretend this doesn't matter. Consequences can range from, yes, bank passwords being seen to a friend overseeing a Facebook password and setting an innappropriate status message that the user's family or boss sees.

Con: Shoulder surfers will still view passwords.

Con: Going "back" reveals the password.

Verdict: Terrible idea.

Providing a checkbox to disable masking (masking on by default)

As I mentioned before, Apple does not enable iPhone-style masking on the desktop. What they often do instead (e.g. when entering network passwords) is provide a toggle (in the form of a "view password" checkbox) so that users may optionally view their password as they enter it.¹ This is a great idea and is much easier to implement than the iPhone-style password masking.

Pro: Enables users to check their password entry if and only if they are confident no one is watching.

Con: If care is not taken to convert the plaintext back to a masked password box on form.submit and page.navigate (i.e when users leave the page), going "back" will reveal the password.

Verdict: Take care of the problem mentioned in "con" but this is by far the best solution.

Conclusion

Masking by default and providing a mechanism to view passwords at will is the best solution.

It should be kept in mind that there are a lot more password-related concerns to keep in mind; consider enforcing strong passwords for users and use encryption, password salts, and hashes server-side.