Jakob Nielsen made quite a stir not long ago suggesting that password masking should go the way of the dodo:
Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn't even increase security, but it does cost you business due to login failures.
Jakob Nielsen
Nielsen argues that providing feedback and an indicator of current status is a basic premise of usability. More importantly from a business perspective he argues that failed logins are costing businesses time in support as well as lost users. That may be true, but here's why we need to mask passwords anyways.
Passwords Mean Security
Passwords are all about security – In some cases passwords are simply about the reassuring appearance of security. A site that has password protection is, to many users, secure – whether the site is really secure or not. When you eliminate masking you might be saving your users a few seconds irritation, but you'll be damaging your own credibility.
Nielsen's research was largely based on mobile devices, but mobile devices have one advantage that desktops do not have – ease of obfuscation. If a phone didn't mask passwords it wouldn't be the end of the world, because users can much more easily conceal their actions on a tiny device than a full size machine.
The (Awesome) Solution
Many smartphones, including the iPhone, solved (part) of this issue by showing the most recent character of a password field with a delay of a second or two. You can see what you just typed, but not the entire password. This provides Nielsen's much vaunted feedback and status, while still retaining the majority of the field's appearance of security. Just one problem: browsers don't do what mobile devices do. So, we'll make them do it with some fancy javascript and a little behind the scenes trickery.
View the Demo »How to Implement It on Your Site
Here's how we'll help your visitors keep their security while improving password masking, with just some javascript and CSS magic.
- Put a standard text input where the password input would be and label it 'password' for the user.
- Create a real, hidden password field which the javascript will copy the password into with a type and ID of password.
- When the user submits the form, send the username and real password fields, while discarding the fake one they typed into. (Since the field they typed into has been converted to bullet characters we can't submit that field).
The Code
This version of the solution is written as a Prototype behaviour and requires the lowpro behaviours plugin, but the code isn't terribly complex and could be adapted to most any system. Here's the behaviour itself:
With that in place you simply have to attach the behaviour when the page loads:
Solved! Sort of.
Does this solve the problem? Well, mostly. It's a nice interaction and it does seem to strike a middle ground between fully masked and Nielsen's total unmasking rallying cry. Security expert Bruce Schneier actually backs this Blackberry/iPhone method, as he refers to it, as an "excellent compromise."
However, it also introduces a few problems: it doesn't work well in older browsers and doesn't play nice with browsers trying to autofill the saved password. The ideal solution is in the hands of the browser manufacturers, and making type=password fields act this way by default as they already do on mobile.
Security online will only become a bigger deal as we and our users invest more and more of our lives in other sites. There will come a day when passwords are seen as hilariously antiquated, and retina scanning or voice identification (or colonic maps, yikes) are the truly secure ways we identify ourselves. Until then we'll keep looking for awesome solutions.
See also:
Super awesome labels
Nielsen's Alertbox on Password Masking
Bruce Schneier 'I was probably wrong'