'Password field unmasking' as an anti-pattern
When I say anti-pattern, it points to the UX patterns which isn’t in the conventional usage, but it could solve a few UX problems and may also introduce new problems. It’s got to be subjectively judged and measured by its impact on the user experience.
I am a member of over 50 social networking sites (5 active, 2 hyperactive), member of some 50 forums, and have signed up with over 500 sites. I have to remember username and passwords for these sites. Adding to my load are my online banking accounts, windows login, folder protector softwares, encrypted zip files and many more. Everytime I type in the password to access any of these, I am not sure about what I am typing. I have to look at the keyboard, rather than the screen to make sure I am typing in the right characters. Most of the time am not sure if the particular combination is the right password. There is always uncertainty until the screen grants access. The reason being that the password field is masked. To overcome this difficulty and uncertainty, we tend to use simpler passwords and make it a unified combo of username and password across all websites. Thus acting like a sitting duck for the hackers out there.
Jakob Nielson suggests that the password field must be unmasked. He further justifies that most of the time there is nobody looking over your shoulders. Also a trained person can see your key-strokes to get your password.
Well, most of the time there are people around me and there is a fair chance that they are peeking into my screen. It’s not a globally valid assumption to make. One is a 100 person could be trained to see keystrokes, but almost everyone can read the typed password if it’s not masked. This assumption fails as well.
The suggested solution is to mask the password field by default and leave the decision to the user to choose between unmasking it or not doing so.
Just like a check box to save the password and remember the user’s session, another check-box can be added to mask or unmask the password field. If user unchecks the check-box, the password field is unmasked and the users can see what they are typing in it.
By default the password field is left masked. It’s the user’s choice to unmask it. A practical example of this pattern is the winrar application.
Saving password in the cache memory and also revealing the password field could be a security issue. The user’s trust is very important in the user experience. To gain the user’s trust we can sacrifice one of the 2 features. The weakest link is the save password field. If the user wants to save password, they can always use the browser’s inbuilt feature to save password and save the session in cache. So we get rid of the ‘Save Session’ feature and present only the mask/unmask password field feature.
This is a little more élite method of tackling the problem. A combination of use-cases are employed to design a pattern. If the user selects ‘Home computer’, we assume that the user is in a private environment and they can enjoy an unmasked password field and also saves their login details for further sessions. If the user selects ‘public computer’, its assumed that the user’s privacy is at stake and the password is masked and not stored in the cache. But this pattern calls for a tool tip. The user has to be informed about the consequences of his choice. The system must speaks in user’s language to inform what’s happening within it and the results of the user’s choices.
In all the examples, its important to gain the trust of the user. By default the password field is masked. The user can continue using the system without having to configure it further. The choice is left to the user and they are given the freedom to decide how their login page acts and interacts.
So, how would you like your log in fields?