Spread the Word: Stop Password Masking
One of my pet peeves is password masking. I find nothing more frustrating than having a log-in rejected, and not being able to verify that it is correct because I can’t see the password. It was quite nice to find out I’m not alone. Jakob Nielsen’s article Stop Password Masking makes a very good case for stopping the practice. It also addresses the exceptions.
Thank you Mr. Nielsen!
Thank you Mr. Nielsen!
posted by Anonymous at 3/01/2010 09:00:00 AM
1 Comments:
I am going to go the route of disagreeing with the opinion here. I know that it is frustrating to have a password rejected and not know if you just did a typo. However The articles from Jakob Nielsen offer little in the form of real impact it has and the desire to have unmasked passwords is a very narrow 'want' of the market.
I would be very scared to have all my sales team go out giving screen casts with unmasked passwords as they log in and out of tools and internal systems. I would rather have a forced mask here than an option or no mask at all. The former is a guarantee that nobody else will see the password. This goes the same for IT people who remote into desktops. The end users will be logging into systems while the IT person watches. You hope your IT people are all good, but it isn't always the case.
If we were to move to optional or non-masked passwords, most internet browsers would have to change their default behaviors. When I frequent a website, it has the option to remember and auto-complete my user name and password. These features work based on the password field being masked. Changing this standard would have a long period of time where another user to jump on my system and see my passwords auto-populate. If that were to happen now, they would at least not know my password. They would not be able to change the accounts password nor see if it works with other accounts I have.
Additionally the option to not mask for web apps would be dependent on the user not having client side functionality disabled or creating an additional step in the log in process. Both cases cause major issues with web development standards and add almost as much time as just retyping the password again.
The argument for more visual password error feedback isn't a real clear point. I don't see typos being a real issue unless you are handed an archaic string of that can't be committed to memory or if you are using a difficult input device like a touch screen. It isn't the case that the system can or should inform you that it looks like you are doing a typo after incorrect log in attempts. And the ideal system should force strong passwords that can be memorized by the user.
Somehow I think the bigger issues with the password typo debate aren't really with he inability to see what you are typing. I think you would find that if all systems would allow the user to create complicated passwords and force a minimum strength, you wouldn't see as many typo problems or people storing their password in some local file. Typos on hand held devices will be inherent until we come up with better software or hardware for user accuracy.
I just can't justify the massive changes in internet browsers, web development conventions, and interruptions in screen casting/sharing for the anecdotal assumption that you could get more IT calls or less business because someone has the one off reoccurring typo with their password. More so when that typo issue can be alleviated with better password creation/enforcement methods. So that is my counterargument.
Post a Comment
<< Home