We've created Zuko, our next-generation form analytics platform. Explore Zuko

Masking Passwords in Online Forms

Form Optimisation

This seems to be a hotly debated topic in the world of form design. The core conflict is between security and usability – yes it would be easy simply to only ask for an email address when logging in or signing up to an online service, but the security implications would be less than great.

On the other side of the spectrum, you could ask someone to enter their password four times and ask for two security questions and a pin, but users will be unlikely to complete this process (unless you are an extremely secure online bank or other security-heavy service).

So what is the right balance, and in particular what are the consequences of masking the password field so that a user’s entry only appears as a series of bullet points? Or vice versa? And will your decision impact the conversion rates of your form?

Twitter log in

Why mask in the first place?

Well, security. The thinking is that unless you are at home, there will be passersby and those often close enough to you to see your computer screen as you type away at your keyboard. When registering for a service, or logging in, were the password to be displayed in full and unmasked, then they could easily make a mental note of your password and get up to various nefarious activities with your details.

One approach to prevent this.

One approach to prevent this.

As many point out though, anyone intent on doing this could simply observe your fingers tapping away at the keyboard and do those same nefarious things. But this is undoubtedly harder than glancing and reading text on a screen. People increasingly use their personal computer in public spaces (I’m thinking of you, Mac-using Costa-drinking creative types), so having passwords display in plain text can be unsettling, even if the security risks are minimal.

But many people simply display passwords as masked for legacy reasons. They do not know why, only that it is the ‘done thing’, and so it should be done. This is not a reason to hide password fields. If you count yourselves as one of those people, then let’s consider some more viewpoints on this issue.

Building Trust

Trust is important to websites – if a website does not mask your password, there is an unsaid implication that the site itself may be less secure than one that masks your password. Just as other symbols of security can positively impact on a visitors perception in other areas (padlocks and seals or badges often feature heavily on payments pages for instance) the fact that a password is masked can also influence a user’s mindset.

Too much. Taken from a real site. Seriously.

Too much. Taken from a real site. Seriously.

Unbounce have written a couple of articles indirectly about the issue of trust when users are interacting with you site, and you can find them here and here. Although they focus more on the general website and checkout process, the basic principle is the same, users that trust your website are more likely to continue to engage with it and eventually, convert into customers.

But again we find ourselves in conflict with usability. If by building trust you make your website less usable, aren’t you equally at risk of driving away visitors who get frustrated with your site?

In the usability camp…

Dr Jakob Nielsen argues that we should show most passwords as text when we type them. His article, Stop Password Masking, has the following summary:

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.

Dr Nielsen also points out two side effects of masking passwords, one of which lowers security:

  • Users make more errors when they can’t see what they’re typing while filling in a form. They therefore feel less confident. This double degradation of the user experience means that people are more likely to give up and never log in to your site at all, leading to lost business. (Or, in the case of intranets, increased support calls.)
  • The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security.

Dr Nielsen concludes thatIt’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.’

The conclusion therefore is that in most situations the password field should be unmasked, and if you have a box to toggle between masked and unmasked, by default the password should show.

drupal.org

drupal.org

His comments are powerful not only because he is an expert, but also because as a rule of thumb he is a fan of convention. Usability is often about presenting users with what they expect to see and how they expect a website to behave when they interact with it. Recommending changing the feature of the internet is therefore a big deal. That doesn’t automatically make what he is saying right, mind you.

Many feel that the password should always be masked as a default (in all situations). In another discussion about masking passwords on forms, Ray McCord argues that ‘It must be masked by default and the user must have to take an explicit action to unmask it — and even then that choice should be honoured only very temporarily before reverting to masked. Why? Because this password form is acting as your agent and it, therefore, must be made to act in your best interest first — like a bodyguard.’

The thinking with this point is that security must come first unless a user chooses to override this concern for ease of use. The website is letting the user down (in a security sense) but auto displaying their password, especially if, like most of us, we use identical or similar passwords for all of our accounts, even the super secret ones.

I am tempted to disagree with Dr Nielsen in this instance, as I do think that a website has at least a minimal obligation not to screw over visitors. If they choose to downgrade security measures, then it becomes their choice.

Internet explorer has this feature built in:

IE10

You password is masked by default, and then clicking and holding on the small icon displays your password. This is an interesting feature, although I am unsure how many people will actually know what this little symbol does. It is also browser driven, rather than a feature of the form, meaning only visitors using IE10 will benefit.

Are log in forms different to sign up forms?

There is an argument that the consequences of mistyping your password when logging in are not as serious as when signing up. If the password you set up originally is one that you remember easily, then you can correct your mistake once told you cannot log in. But enter it wrongly in signing up, and you will have to reset your password and follow the lengthier process on changing your password.

But the same arguments apply as above, making the sign up as usable as possible may backfire if users have an adverse reaction to your slightly unintuitive choice to display all password as default. If your concern is to ensure that users do not make a mistake in their sign up, is there another way other than masking or unmasking a password field?

Password confirmation fields

One way to keep masking but to make sure that a user does not incorrectly make a typo in setting their password is to have a confirm password field. The validation checks (or should check) if the passwords match and let you know if there is a discrepancy between them.

Password match

Problems with this however include that if the passwords do not match, the user has no immediate grasp on where they made the mistake, so may in fact have to retype both. Given that users will typically make a mistake every X times they enter a password, asking them to enter it twice increases the probability that they will make a mistake, and as already mentioned they may have to correct this mistake twice.

So confirm password may not be the best option from a usability standpoint either, and it will certainly affect more numerical indications of form usability, like time taken to complete it and corrections.

Different on mobile?

With many mobile devices, a different approach is taken. When you type a password in a field, the last key pressed displays, until you press the next one. Given that you are looking more or less directly at the screen as you type, you can see if you are entering your password correctly, one letter at a time.

Password mask mobile

Taken from http://www.lukew.com/ff/entry.asp?1653

This is different for a lot of users on desktop computers, as many of them will look at the keyboard as they type, and therefore will not be able to see the letter appear. Additionally, most type faster on a keyboard than on a mobile device, so the benefits may be lost because the letter will only be visible for a tiny fraction of a second. This will also be the case for less confident typers on a phone and tablet screen, as they will focus almost entirely on the letters, so by the time they look up, most will be covered by an asterisk.

This is not the only approach adoptable on a mobile device however. Luke Wroblewski worked on an app called Polar, where the default option was to display the password, giving users the option to hide the password if they wanted to:

Polar

Luke explains their thinking:

We decided to optimize for usability and ease of log in over questionable security increases. On a touchscreen phone, it’s trivial to move the device out of sight of prying eyes. Or easier still to simply hit the Hide action to obscure a password.

Here’s his full write up, but Luke argues that given the environment and device that people would be using the app, it was better to place more importance on usability than security.

So, in ••••••••

Put in a reasonable level of security and let the user reduce this if they wish. If the default option is always on the side of usability, then people will get caught out. Which has bigger implications, a user entering their password wrong, or their account details being stolen?

Security measures are supposed to be in place regardless of the environment. Of all the suggested solutions I have seen, I find the option to unmask the most appealing. Yes, users will mostly do the default action and therefore leave the field masked, but especially in situation and for sites where security is of increased concern, this is more desirable than having them unmasked as a default.

We shouldn’t do things the way they always have been done for the sake of it, but taking a similarly radical approach putting usability at the forefront of form design can cause consternation in users and may equally impact how effectively users can complete them. What’s your take, and have you seen any bad or good implementations of any of the above?