Setting a password is tricky. You have to come up with a sequence of characters that you can remember but other people will have trouble guessing. It is no easy feat. To make matters worse the typical user interface for setting a password is hard to use. This is because of password masking: where a character (usually a * or a • ) is used to replace what the user actually types.
The idea behind password masking is to prevent people looking over your shoulder and learning your password. However, the user cannot see what he or she is typing so it is hard to spot a mistake. A password with a mistake makes it hard to log in. So we end up getting the user to enter the password twice ? in the hope that he or she will not make the same mistake a second time.
Last year the usability guru Jakob Nielsen called for password marking to be dropped. And the security guru Bruce Schneier agreed with him. It pays to listen when high-profile experts on usability and security say things need to change. I did listen and started a lively debate about forms on GroupServer.
As a result of the discussion I ended up changing how GroupServer treats passwords:
- When setting a password GroupServer presents the user with a normal text entry that shows what the user has
- When signing in GroupServer presents the user with a normal password-entry that masks the password.
When setting a password the user can easy spot an error if he or she makes a mistake, so there is only one entry. Because setting a password is a rare event it is unlikely that someone will be looking over the user’s shoulder. However, entering a password when signing in is a common event, so we still use masking in that case.
We have been using the system on OnlineGroups.Net for about a year now. It has worked very well, and we now get very few requests from people who have trouble logging in.
However, reading back over the topic (which discussed forms in general) I realized that I have not finished my improvements to the password entry. What is currently missing is a checkbox on both forms, which would allow the user to toggle the masking, much like the Show password checkbox on the Edit Connection dialog in GNOME. Because the toggle is missing it looks like we made a mistake, as plain-text password entries are the exception, rather than the rule. At least I have Trac to remind me to fix things.
Update October, 2014
One of the changes that was made with our new UI has been to add a toggle to both the Sign in page and the Set password pages. The default is the same as outline above, with the password hidden for sign in, and shown for setting. However, you can check what password you are using, or ensure people cannot look at your password over your shoulder.