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:

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."

  • 13
    @Izquierdo I sure hope not! Any site that is able to show me my unmasked password upon request proves to me that they are storing my password in a reversible manner (e.g. in plaintext, or some reversible encoding), which would be a huge security vulnerability. Sep 29, 2022 at 19:35
  • 7
    @nd. Be aware that making the unmask function "spring loaded" as you describe could present accessibility issues. This is an uncommon UI interaction method that may not be ideal for users with fine motor control issues. Sep 29, 2022 at 19:40
  • 2
    A minor comment: While password-unmasking has its advantages like described in the answers, it may be worth to disable copying and other programmatic access to the input field. DO NOT disable pasting, as you will prevent people from using password managers, which allow people to use much stronger password than they would use without a password manager.
    – allo
    Sep 30, 2022 at 11:34
  • 4
    Don't forge to add spellcheck=false: androidpolice.com/… .
    – GACy20
    Sep 30, 2022 at 12:30
  • 2
    I like most answers. As someone who works in security, I'd just like to add: security is not a mathematical science. The idea of a "security score" is preposterous and counterproductive. Someone writing a security review should be able to justify a finding beyond saying "it is insecure", and in this particular finding seems to ignore that passwords are (supposed to be) convoluted gibberish typed by people, beings who are famously forgetful, clumsy, nervous and distracted. Allowing them to double-check is the least we can do for them. Oct 5, 2022 at 18:51

3 Answers 3


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
  • 15
    As an example of why denying unmasking is counterproductive, I had to log on to a touchscreen device (MFD printer) recently, with only a masked password field. On the third try (after discovering that the keystroke rate was limited) I was forced to, for each character: hover over the onscreen key, move my attention to the password field, tap the key while watching for another dot to appear in the box. Anyone within about 3 metres or watching on CCTV would have been able to read my password from the keystrokes (large) while moderate-sized text would have been far harder to read at a distance
    – Chris H
    Sep 30, 2022 at 7:54
  • 5
    Agree 100% with the NIST. The "mask the password" thing made sense 40 to 50 years ago, when people were logging in to terminals attached to a mainframe or minicomputer, in a shared lab. Nowadays, 99.99% of the time when I'm logging into a secure service on the web, the only other person in the room is my wife, and if I can't trust her with my passwords, that's probably indicative of something that could be grounds for divorce. Granted, parents with children may need to keep some passwords secure, so the ability to mask should not be completely removed
    – dgnuff
    Oct 1, 2022 at 8:30
  • @dgnuff, surely you're not recommending for a design to fit your particular situation? I often find myself drawing out a design in a coffee bar, surrounded by lots of people working on their laptops. Oct 1, 2022 at 8:41
  • 1
    @RoAchterberg In one respect, yes I am. Because as is noted by others in answers and comments for this question, my situation is extremely common. That's why password unmasking is becoming the norm nowadays.
    – dgnuff
    Oct 1, 2022 at 8:46
  • 5
    @RoAchterberg Agreed. That's exactly what I'm proposing. The UX should mask initially, but it should also provide the ability to unmask. The initial masking is essential to deal with either parents logging into their bank with 14 year old irresponsible children in the room, or anyone logging into a service at (e.g.) a public library. The point I'm trying to make is that is is equally essential to provide the unmask feature.
    – dgnuff
    Oct 1, 2022 at 8:55

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.

  • Regarding the "foreign concept": My logins usually go through 1Password and I almost never interact with a password field, so maybe I missed this somewhere. Checking with Safari & Firefox, of of the sites I visit frequently (Stackoverflow, Reddit, heise.de, Steam, Google) only Google has a checkbox for showing the password, but due to 1Password I haven't seen this until now.
    – nd.
    Sep 29, 2022 at 13:12
  • 10
    I often use password unmasking even when using a password manager, to quickly verify that the password field hasn't quietly shortened the password entered to some max size...... Sep 29, 2022 at 19:45
  • 21
    In support of this answer: it can be maddening to be entering a password and have it repeatedly fail and just NOT KNOW what's wrong with it. Being able to unmask is an important troubleshooting option for a user to be more successful. The problem with security measures is that the more secure something is, often the less usable it is. Adding the usability feature of unmasking passwords actually aids in security because users who are blocked will more assiduously act to circumvent security controls (such as intentionally choosing weak or easy-to-type passwords).
    – ErikE
    Sep 29, 2022 at 21:17
  • 11
    What @ErikE said is especially true when creating passwords on a system that has very high complexity and length requirements. Without being able to toggle visibility in the actual password field, the user is likely going to use something else as a "scratch pad" to create their password and copy/paste it in. That somewhere else could be another app, or in the case of a browser might even be the URL/search bar and their password ends up getting sent to some search engine as a search term.
    – Herohtar
    Sep 29, 2022 at 21:32
  • 5
    Re. password managers: unless you have one installed on every platform you use (phones, tablets, personal laptops and desktops, work laptops and desktops…), then you'll sometimes have to type in a password even if you use a password manager to remember it.
    – gidds
    Sep 29, 2022 at 22:37

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.

  • 7
    "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" - that's just plain wrong from my experience. Logging in to websites (and elsewhere) happens all the time, while you are giving a presentation, while you are sharing your screen during a video call, while working together with your colleagues in the office.
    – Bergi
    Sep 30, 2022 at 7:09
  • 5
    This is an article from 2009, before password-managers were integrated into OSes/browsers, before most interactions were on mobile where you could be standing in a crowded subway, so I don't totally agree with that. I am aware that unmasking is a feature that people like (see Followup 1), but as long as there are passwords, I think the default is that they should be masked. This also gives password managers a clue what input field is supposed to contain what. If some credential is for one-time use like an OTP, then go ahead and unmask it.
    – nd.
    Sep 30, 2022 at 10:49
  • 1
    Entering a password in a crowd ... how common is that? Don't the vast majority of apps get signed into once? The percentage of users using the password in that scenario has to be way less than .0001 and the percentage of those users that don't know about typing a password in front of people shaves off a huge chunk of that number, the majority of the remaining percentage is getting their keystrokes read, not the screen read, so the number is even smaller
    – moot
    Sep 30, 2022 at 20:02
  • 3
    "sitting all alone in your office". I suppose that was written in a century when people actually got their own offices, instead of sitting in an open-plan row with someone 4' to their left, 4' to their right, and 4' behind them.
    – hobbs
    Sep 30, 2022 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.