Is password-unmasking worth the potential security downside?

Question

I work on the iOS implementation of a mobile application where the (cross platform) design guide specifies an unmasking-control for password fields. I am primarily an iOS+Mac user, so this concept was foreign for me, but I did implement it.

Recently, there was a comparison of our app alongside others in an external publication, and we did get less than stellar scores for "security". One of the issues apparently was that a potential attacker could copy the password from an (unmasked) password field.

As a resolution for this problem I suggested that we should get rid of the unmasking-feature, also noting that unmasking is a non-standard pattern anyway. Other team were very adamant that they really like this feature, and that all platforms other than Apple's do have a standard password-unmasking UI in password fields.

We cannot have both – a better security-score and unmasking – so what is the best tradeoff to argue for? Our application does shows privacy sensitive data such as invoices and has features that potentially cost money if (mis-)configured.

I did read the following articles:

• Should password fields have an unmask checkbox?
• Nielsen's Stop Password Masking
• Password UX: the Real Problem

My current opinion is that this arguments from ten years ago are flawed: Making passwords visible at the entry-box makes it harder for users to discern what things are supposed to be secret and doesn't really solve the UX issue with passwords. Password managers or passwordless login systems are a better way to tackle this issue. I would argue to use the platform-specific password-entry field and not add functionality on top of it.

Followup 1

For my comment on the entry of Ro Achterberg I found an interesting implementation of this concept on Windows 10:

Password fields have an unmask-button that only shows up if

• The password field was empty before focusing it
• There is at least one (masked) character in the field

The button is spring-loaded: the password is only unmasked while it is actively being pressed; clicking on it does not move the focus out of the password input.

This looks like a very sensible compromise: Users can check if they entered the correct password, but they cannot uncover passwords from other sources. The spring-loaded nature makes it also a bit more inconvenient to screenshot or copy the text out of the field (on mobile).

Followup 2

Based on the discussion I was made aware that many more people than I expected really like the unmask password feature. A remaining question then is: "If the platform's standard controls do not support such unmasking, should I go out of my way and re-create it, or should I wait for the platform to catch up."

Answer 1

This is current recommended best practice by NIST

The people who dinged your product for security issues are not up-to-date with current standards. In 2020 NIST published updated password guidelines that reverse many traditional "best practices" that have been shown to be detrimental to security in practice. Among those, they specifically recommend to enable display of passwords while entering before submission, and to allow copy/paste passwords (although not explicitly said, the latter is probably more to allow paste into a password field than copy out of).

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.

Some other recommendations that reverse some traditional practices:

• disallow password hints completely
• do not force periodic password changes
• limit password complexity requirements in favor of enforcing longer passwords or passphrases

Answer 2

I'm a little surprised the pattern is so alien to you, and have to agree with the others on your team on this (sorry). Providing a visibility toggle for the password is a fairly common pattern across the web. Remember, even if you cater to Apple users on your native app, their expectations of password input affordances are going to be trained by use outside of the OS as well. You'll find that most larger websites add a visibility toggle to the native control.

In my opinion, providing an unmasking feature is perfectly valid for these reasons:

1. An interface will be clueless as to who else is in the room that could be "shoulder surfing".
2. Even if a system enforces minimum requirements on passwords, people will still go for something that's easy to remember. 'Easily remembered' pretty much unpacks to 'weak password'. You've noted correctly that a password manager is the better option. Yet we all know that people will continue to be lazy and prefer to memorize their passwords (and reuse them across their accounts as a result of this).

As such I would argue that it is best to:

• Put the user in control of whether to show/hide the password. A user will be aware of their surroundings, whereas the interface won't.
• Default the input to the masked state.
• Adhere to common practices. People come across a wide variety of password implementations, most of which will offer an unmasking feature.

With respect to the security checklist you're referring to, I have to disagree that potentially showing a password will be inherently insecure. IMHO, the unmasking feature is a pretty decent trade-off, at least for as long as we have to deal with passwords.

Answer 3

Norman Nielsen Group's article on this issue gets it right:

Stop Password Masking

By Jakob Nielsen, June 22, 2009

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.

It's time to show most passwords in clear text as users type them. Providing feedback and visualizing the system's status have always been among the most basic usability principles. Showing undifferentiated bullets while users enter complex codes definitely fails to comply.

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users' shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn't even protect fully against snoopers.

More importantly, there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

The Costs of Masking

Password masking has proven to be a particularly nasty usability problem in our testing of mobile devices, where typing is difficult and typos are common. But the problem exists for desktop users as well.

When you make it hard for users to enter passwords you create two problems — one of which actually 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.

Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they're using an Internet cafe. It'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.

In most cases, however, users will appreciate getting clear-text feedback as they enter passwords. Your business will increase, and security will even improve a tiny bit as well.

Abandon Legacy Design

Password masking has become common for no reasons other than (a) it's easy to do, and (b) it was the default in the Web's early days. In this respect, it's similar to another usability problem — having Reset buttons on forms, which is also something that should die.

Generally, I recommend adhering to conventions. Do what users expect, and they can concentrate their brainpower on understanding your products and offers instead of struggling with the user interface.

But password masking and Reset buttons are not something users actively seek out. Losing these features won't cause confusion, nor will their replacements: the new features will simply be clear text (in the first case) and a blank area where the destroy-my-work button used to be (in the second).

This is very different from removing something users look for or introducing something they don't understand.

Let's clean up the Web's cobwebs and remove stuff that's there only because it's always been there.