How to Mask Passwords Like the iPhone by Jonathan
July 10, 2009 in Interaction Design, Implementation with 13 Comments
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.
Users expect masking for their own peace of mind.
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.
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'
13 Comments
Karl Wångstedt says:
One disadvantage with this solution is that it doesn't work if you misspell, delete the password, and start typing again. Or if you just delete the last typed character. They will still be present in the hidden form.
I guess it's possible to fix that with the JS, but is it worth it?
Nielsen's proposal is still a better way, in my opinion. I think that IT peoples need for a "appearance of security" is not something that users share. Normal users want a UI that is easy to understand and that make sense. If that's not the case, they get frustrated and angry. And angry users are not a good thing. That's when you get passwords on postits next to the screen.
Jonathan (ZURB) says:
@Karl Yeah, there are some kinks in the implementation but happily the Decaf blog cooked up a jQuery plugin that resolves some of those issues (albeit in some cases by not allowing mid-string editing).
iPhone-like password fields using jQuery - Decaf blog
As for users, you're absolutely right users want a UI that is easy to understand and makes sense, but we can't ignore actual security implications. Bruce Schneier made some great points about the issue on his site, most notably that there are real security concerns when it comes to password fields. Shoulder surfing, or hovering over someone to get their passwords, isn't much of a problem for people - but is that because passwords are masked?
Schneier also says that masking is not a panacea, and he's right. Masking is a stopgap like anything else, and it comes with (as you correctly mention) plenty of downsides. Maybe we need to just switch to retinal scans ;)
Chris says:
It's amazing how concerned people get about others stealing their passwords by looking over their shoulder ... while they surf at their local coffee shop over open WiFi networks.
Oliver Nassar says:
Great post and insightful idea. I'll be porting this over to mootools and will follow up with a link to it under an MIT license. I'll try and fix the problem with the backspacing/deleting of a character as well.
One mod I'll probably make is the ability to have it run on it's own, by checking the DOM for an input[type=password] nodes and automating it for a drop in solution.
Great inspiration.
Jonathan (ZURB) says:
@Oliver Awesome! Until browser manufacturers address this on the binary side libraries like moo, jQuery and Prototype are our best bet toward making this easy to implement and fool-proof. Be sure to let us know when you've ported it over, we'd love to see it.
Anton D Peck says:
I love the idea behind this. It would be excellent to see browsers begin supporting a similar method of feedback. Thanks!
David Moreen says:
I like the idea and the smoothness, but I use jQuery on my site.
Jonathan (ZURB) says:
@David You're in luck! The Decaf blog wrote up a very similar implementation as a very simple jQuery plugin. You can find it here:
Decaf Blog: iPhone-like password fields using jQuery
Jose says:
Excelent ideia. Congrats.
Ps. The backspace is not working, or is it just me?
Jonathan (ZURB) says:
@Jose Thanks! This implementation is a little buggy, we admit - it's tricky to get a really smooth interaction with the current tools available. Might also depend on the browser you're using, as javascript implementation isn't quite the same on all of them.
Joseph says:
I went over to the Decaf blog to check out the one that they have over there. It works nicer and everything, but after reading the comments on that page, I'm not so sure this is a great idea. One person gave an example of using a projector and if he started typing his password there people would be able to tell what it was (unless he types really fast). In any case, this was designed for mobile apps for a reason. It's not really applicable to desktops and people might be confused by it at first.
Also, a suggestion that might make things easier is to not display the character inline. just make a small box pop up somewhere nearby that displays the most recent character typed. I'm not really advocating the use of it, but I think it would accomplish the same thing and be a little easier to implement.
I believe in the method that Mac uses on their desktops where passwords are masked by default, but you can click a check box and have it appear as plain text if you prefer. Obviously the default would be to mask them. I think this is more secure and works nicely for a person to make a quick check to see if he/she typed the password in correctly or if their really bad a typing they can have it on so they can see every character they type.
Jonathan (ZURB) says:
@Joseph The projector situation is a good example of where more security is really warranted - the same could be said for a library or computer lab, or any really public space.
The way Macs handle passwords (the checkbox) is a good idea, even if the implementation is a little clunky. However, you can't find that in browsers right now. This might be a good thing to explore in a followup - how can we gracefully allow people to see what they've typed without losing security?
Martijn says:
This is not just to mimic the iPhone. Symbian phones do it like this too, and have done so for years. So instead of saying "like the iPhone" it should be "like a smartphone" because I suspect WinMob, WebOS and Android do something similar.
On top of that, you should need this at all, since obviously, phones already do this by themselves!
Add your comment...