Confirming Passwords Is Annoying: Is There a Better Way?
28 Comments
The defining characteristic of a password field is that it abstracts text as dots. While the intention of this behavior is understandable (it makes users feel secure and protects from prying eyes), the unintended effect is that it creates a usability problem. Users can't tell if they've entered a password incorrectly until after the site's validation informs them. It's like typing with your eyes closed.
The most common solution for the password field problem on registration pages is to require people to confirm their password in a second field. Again, the intention is understandable (it cuts down on mistakes), but the reality is that sites are requiring people to deal with two password fields. Here's an example of the common solution with some JavaScript validation:
Demo
While this isn't a terrible experience, I think there are a few other ways to handle this problem worth exploring. With some inspiration from a post on IxDA.org, I've created three below. Of note, all of these proposed solutions load a password field when the page is generated, so the browser will initially treat them as regular password fields.
Solution #1: Users click a checkbox to show characters
Demo
Pros: The decision to show or not show characters is fully at the discretion of the user. Passwords can be edited while characters are displayed.
Cons: It doesn't automatically switch back to a password field. People could accidentally keep it checked while they're filling out the rest of the form, leaving the password susceptible to prying eyes.
Solution #2: Users hold down a button to temporarily show characters
Demo
Pros: Users are able to see their password characters if they'd like and cannot accidentally leave the field in the show character state. This solution potentially feels more secure to users than solution #1.
Cons: The downside is that users cannot leave the field in "Show characters" mode while they're editing the field. They can only see what they've entered when the button is pressed down.
Solution #3: The password field automatically changes to show characters
Demo
Pros: As a user, this approach would be my personal favorite because it's the easiest option, and you always see your password as you're typing it in. I don't really care about other people seeing what I type, since I rarely find myself in situations where I notice or would expect people to leer at my screen.
Cons: When users first select the field and start typing, it will look and behave like a regular text field -- which may be startling to some. Users will not see that it switches to a password field until after they've entered something and clicked off of it.
Conclusion
None of the solutions presented here are the silver bullet for how to handle password fields in all situations. Depending on your users, your goals for the form, and your willingness to try something a little extraordinary, one of these options may make sense for your site. If anyone has any other ideas for how to handle password fields, I'd love to hear about it in the comments.
Update! April 16, 2009
In response to this post, Stephen Lewis from Experience Internet put together a writeup and demo for another alternative to password confirmation. His works very similarly to the iPhone password input field where the last character is momentarily a character before automatically switching to password "bullet".
Interesting article - I like solution #2. I’m not sure there exists a silver bullet for all audiences or applications - Someone will have trouble regardless.
I’ve not implemented it, but I’m fond of the iPhone style password entry where all but the last character is masked when typing. As a user it removes the annoying necessity to repeat my password and gives me confidence that I have typed my password correctly while remaining relatively secure from prying eyes.
@Brandon - I thought about the way the iPhone treats password fields as well. I couldn’t think of a clean way to implement that without using some really kludgy JavaScript.
Not sure if this is possible, but could the password be dynamically displayed below the password field? Maybe obfuscated ala CAPTCHA so someone passing by wouldn’t be able to see it?
Might take a lot of javascript to log what someone types, and might be abusable to hackers, but it’s an idea.
I don’t see much of a benefit to displaying it CAPTCHA-style other than annoying users who can’t read CAPTCHA half the time (me). It’s not really a standard behavior or one that is easily learned by those who might be unfamiliar - I don’t think it would pass the parent test. Also I don’t think it would be any more ‘abusable’ by hackers than any other option though.
@Ben - Interesting idea. I think that could be done, but I’m not sure I would like it as a user. Generally, CAPTCHA text annoys me because it’s hard to read.
The CAPTCHA part of the idea was just to make it so that someone walking by couldn’t see. If that’s not a problem, then just generate it below as normal text. Otherwise maybe generate it below with a “Hover here to reveal” ala spoiler alerts on IMDB (http://www.imdb.com/title/tt0830515/)
@Ben - I think the “Hover here to reveal” idea would work. Would it be better to change the reveal the text inside the input field, rather than displaying it somewhere outside the field?
I think probably outside of the input field, if only because when you hover over the input field and it changes to text, and you go to click in it, you’d expect to be able to edit that text that you can see, but it would revert back to ******. Maybe once you hover and click in it it could switch to text, but then you have the problems that you’ve described already. I think a simple “hover over to see and visually confirm” should work, and requires 0 clicks (the bane of good UI, right? :P).
- those obfuscated passwords are for the the others not to see what you type, what do you do, look all directions and press show?
- i thing the most usable way is not to have password confirmation at all. the system sends you an email with the password on registration, which you can easily change if you typed wrong.
@usability thoughts:
Most of the time, the obfuscation isn’t necessary.
Secondly, there are a few problems with your latter suggestion. It’s a best practice to never store the actual password in the system—the backend hashes the password for use later, but never actually stores the password you entered. By emailing it to you, there’s a solid chance it was first stored in the database, and then it’s transmitted in cleartext through one or more intermediaries (email almost completely consists of cleartext transmissions).
- you can’t know where your user is, in a cafe, internet cafe, on the street, you have to consider his privacy.
- clear text, not necessarily, the password can be send in clear text on register and stored with a hash in the DB. The mail goes from server to server so that’s not really an issue.
Personally I hate having passwords emailed to me. I’m much more likely to have my email logged in and someone finding my password than I am to allow someone to look over my shoulder and see one on the screen.
Maybe the answer is to not have password confirmation, but make it so that if you fail two or three tries, you’re alerted that you might have typoed your password, and that you can start a password reset request. It would be interesting to see what percentage of people would actually mess up their password with one try. I know I can’t remember the last time a password confirmation told me my passwords didn’t match.
requesting a password recovery it’s the same as receiving a registration mail. :)
if someone has access to your email, has access to all your accounts registered with that email, so again, it’s not really an issue.
I don’t think it’s the same. It’s only similar if you need to use it, but 90% (a guess) of people won’t mess up their passwords at first anyway, so they’ll never have to do the password recovery.
And yeah, you’re right about having access to all your accounts anyway (for the most part), didn’t think about that.
Yeah, I’m not sure there is a perfect solution here. =)
There is no perfect solution when we talk about usability, you’ll always have to improve because users evolve. You have to find the best solution at this time, according to your application and your users.
I sort of had a revelation watching again the examples:
the user doesn’t start with the premise his password could be wrong or it can contain a typo. he assumes he wrote it correctly and doesn’t check it.
so the “show password” features are kind of useless.
@usability thoughts - I don’t necessarily agree with that assumption. On a registration form that doesn’t have a confirm password field, I would definitely want the option to check if I entered my password correctly. Option being the important part of that last statement, it doesn’t hurt users at all who just want to skip it.
I’m not crazy about any of those solutions, they all require extra work on the user’s part. I.E. taking hands off the keyboard to click a button or checkbox to view the password then return to the keyboard to type more data into other fields.
I also agree that most users probably DO expect errors in their passwords, I know I do. If a site has no password confirmation, I definitely second guess myself as to whether I typed it right.
One solution that has been discussed here that I favor is the displaying of the password separately from the input box. However, I think this approach can be improved upon.
Unfortunately I can’t at the moment write up a demo to show, but what I picture is this:
As you type in the box, your password shows up below the box in a lighter tone of text color (or opacity). So on a site like this, it might be a light grey color. Put this “confirmation box” on a js timer, so it disappears after 1-3 seconds of inactivity. Typing another character refreshes the timer.
There are various other ways one could improve on this depending on how much js is available or they are willing to create.
I think this method is best because it allows the careful observer (the user) to see the characters inconspicuously show up below the input box as he/she types, but due to the lower opacity/fontcolor someone passing by probably wouldn’t notice it without taking a double take or really lingering to pick it out. After a few seconds, it disappears and the user can scroll the page without worrying about prying eyes.
How about writing it below or above the input field in a very tiny font so that shoulder surfers won’t be able to see it.
Hi Kevin,
Thanks for the interesting article.
It got me thinking about one alternative that you didn’t mention, which is used for password entry on the iPhone — that of displaying the last character entered for a couple of seconds before obfuscating it.
I’ve knocked together a quick JS demonstration of how this might work in practise.
I’d be interested to hear your (and everyone else’s) thoughts.
Cheers,
Stephen
How about in-page validation with Javascript? Just confirm that the two text fields are the same… Or am I missing seomthing really fundamental? (I may well be, IANAWD...)
Sigh, re-read it, saw the original in-page validation and still posted the above comment =)
Seriously though, why is that so bad? I’d much rather have to type my passwords again than risk someone seeing them, even for a moment. And as my passwords are non-alphanumeric gibberish, I’d be looking at them for more than a moment while I figured out the difference.
Some Unix logins don’t even show asterisks for passwords. The length of your password is another bit of info that other people don’t need to know.
@stephen - Thanks for putting together that post and demo. I’ve added an update to the original post linking to it. I’m playing around with your demo now and wondering how well the iPhone experience translates to a full screen/keyboard. With the iPhone, the primary reason I think they use that method is because it’s much more likely on that device to accidentally hit an incorrect key. Also, iPhone users will always be staring at their screens because that’s where the keyboard and password field are. As you mentioned in your post, keyboard starers on full-size computers might have trouble.
@dave - The confirming password thing isn’t necessarily a bad approach. In fact, it’s the one I’d recommend because it’s the most standard way of dealing with password fields and users are familiar with it. This post was born out of my personal annoyance with having to retype fields and I wanted to conceptually explore some other possible ways.
guys, Apple didn’t invented that obfuscating method, my old 3310 used to do that too.
Interesting, I hadn’t realized older Nokia phones used that method. At this point though, I think more people would recognize it from the iPhone than any other device.
@kevin:
Thanks for updating the post. You make a good point about the suitability of this technique to devices where the keyboard and screen are closely aligned (or in the case of the iPhone, one and the same).
It’d be interesting to see how any of these ideas fare in usability tests against the standard password / confirm model.
@usability thoughts:
I was just using the iPhone as a (prominent) example of this in practise — apologies for any offense I may have caused to Nokia lovers ;)
One last general question… am I the only one who just copies and pastes from the password field to the confirm password field (not on the iPhone of course), thereby rendering it completely useless?
Cheers,
Stephen
@stephen - You’re definitely not the only one who just copies and pastes, I do that almost every time. That’s part of my overall dissatisfaction with the confirm model. To me, it’s just an extra step with little value.
I hate it much more when I’m forced to retype my email adress (which is usually visible) then retyping my password. This is bad user experience to me.
Actually my password looks really weird to me when I see it not in bulletpoints occasionally so I prefer to retype it.
BTW: your blog should clearify it inside this comment form that providing an email is necessary.
Next entry: Sure, Those Colors Look Nice - But Can You Prove They'll Work?
Previous entry: Embracing the Curve
Recent Comments