The problem with displaying passwords
Tuesday, March 2nd, 2010
Last year Jakob Nielsen created a bit of a stir in the web community with his article stop password masking. In the article he quite rightly points out that only displaying a list of bullets as the user types in their password creates uncertainy about whether the password has been entered correctly and results in failed logins. He calls for the use of clear text when entering passwords so users can see if they have mistyped a password.
This caused a lot of controversy as it places the usability of the users interaction before security considerations and challenges an established convention. However, as he points out, many people are accessing sites in situations where they are not over looked and making it more difficult to enter passwords may causes users to choose simpleless secure passwords. This is particularly true with mobile devices where users often enter shorter passwords to make it easier as they have a numeric keypad. He also argues that obscuring the password does little to protect the password anyway since if someone wants to work out your password they could always look at the keyboard. However, if the password is on screen it is certainly easier to see from a distance if for example you are working in a open plan office.
His objection may be correct, many people will be entering a password in a situation where they are not overlooked and making it difficult for these users just because some people are does not necessarily make sense. However, failing to mask password characters may have wider implications. As the site does not mask the password it may create the perception that the user does not need to safe guard this information resulting in more careless behaviour.
Jakob is aware displaying the password may not be ideal in all situations and suggests that a control could be provided allowing users to select to hide their password. This approach is currently used within windows network settings and some WiFi software. In a recent article on list apart Lyle Mullican explores this approach in more detail. However, theapproach places the responsibility for managing whether the password is displayed with the user and adds complexity. It is also a modal control (the user selects either to display asterisks or actual characters) which can cause usability issues. For instance, the user may start typing the password without realizing it is being displayed revealing it to those around them.
IE 8 password entry dialogue allows the user to select whether the password is shown.
Chris Coyier in his article Better Password Inputs, iPhone Style suggests doing something similar to what is done on the ipod touch/ iphone interface where only the last letter is displayed on screen. This is fine for a mobile device where the user can take steps to ensure no one is looking at the screen while they input the details but may be an issue when displayed on a monitor. Users may also fail to notice mistakes when they press another key immediately after they mistyped.
An alternative approach which addresses many of the issues is to hide the password by default but provide a button that when held down reveals the password. Although the user doesn’t receive immediate feedback they have the option to check their password before submitting and the user could hold the button down while typing if required. This approach highlights the importance of keeping the password secret and only shows it when the user expressly indicates it is safe to do so. It also removes the chance of users accidentally revealing their password. This is not necessarily an ideal solution in every case and there will be instances where it is best to display the password in full by default. However, assuming thew user is entering a password in a private office or passing all responsibility for safe guarding secrecy to the user are not ideal whatever the usability issues.
