Password masking in registration forms

29 Aug 2011 - 10:20pm
4 years ago
15 replies
2224 reads
Neil Lee

Hi everyone -

Some context: I'm working on a redesign of a login & registration system for a large web site. User registration is required to post comments to stories, subscribe to newsletters and post media (photos, video) for public viewing only. No financial or private data is stored other than publicly posted information.

One of my personal goals is to reduce the amount of user anxiety and friction involved with registration. I've seen some research (that I can't find now) that shows masking the password during the ubiquitous "enter password / enter password again" process is often where the most user anxiety occurs. I've also read Luke Wroblewski's musing on removing the masking completely with interest.

Has anyone seen any other research regarding registration flow and the usability / security implications of unmasking passwords during registration?

My gut instinct is that we've settled on the dual password field & masking simply because that's the default for the form input, and that in many instances where the user data being protected isn't critical this security measure can be dropped (especially on mobile). The analogy I think of is the difference between signing up for a new bank account vs. signing up for a library membership — one obviously requires a higher level of scrutiny and security than the other.

I'm trying to find data to validate or invalidate this idea and any data whatsoever would be very helpful.



30 Aug 2011 - 2:05am

Hi Neil,I think i have seen a couple of solutions for this and one i like is making the password field with visible text (No *******) in the registration form, So if you can see what you have entered you need not to re-enter it to confirm and so no need to confirm password field. Made sense to me

31 Aug 2011 - 6:05am
Richard I. Anderson

Given that lots of people still often use the same password for everything (no matter how unwise that is), failure to mask might not be well-received. That one time the entering of the the password is seen by someone else...

I appreciate the question, though, as I had missed the prior "musings" by lukew, Jakob Nielsen, and others.

Richard I. Anderson "User/Customer Experience" Practice, Management, & Organizational Strategy (increasingly focused on social innovation) (in hiatus) & &

7 Sep 2011 - 1:53pm
Dana Chisnell

Hi RIchard,

Shoulder-surfing happens a LOT less than social engineering. It's much more likely that someone is going to get your password by asking seemingly innocent questions or favors than by looking over your shoulder.

That said, I was standing in the gate area for a flight the other day when I heard a young woman give her phone number and her credit card number to someone she was talking to on her cell phone while she was using a Bluetooth headset. Whether her password was masked on her phone was the least of her problems.


31 Aug 2011 - 12:05pm
Brian Mila

I thought Luke's position was that it was unnecessary to mask on a mobile device app because there is some physical security present (the ability to easily block the view from others, similar to typing in your pin at the ATM). If I'm not remembering this correctly, and he really was proposing to show plaintext passwords on regular web apps, then I'd say that's really pretty stupid. Many people use the same password for multiple services....would you really want to someone else to get what is essentially your single sign on password because they watched you log into facebook or whatever at the library? The number one rule of security is that a plaintext password should never be visible, ever. The only time I ever see a plaintext pw is in a password reset email where the pw is a time-sensitive, one-time use pw. Even so, I would rather have a pw reset URL instead of a pw in the email.

31 Aug 2011 - 2:05pm
Neil Lee

Wednesday, August 31 at 01:31 PM Brian Mila said: > Many people use the same password for multiple services....would you really want to someone else to get what is essentially your single sign on password because they watched you log into facebook or whatever at the library?

I was specifically referring to just registration flow, not log in, which I agree should be masked. That said, Facebook does something interesting if you mistype your password during log in - in some instances they re-display the login form but unmask the password field. I can't reproduce this now, but I've seen this offered a few times when I've logged in.

I think we'll try using a single field with a "hide/show" checkbox beside it. Now, of course, the question is whether it should be checked or unchecked by default. :)

31 Aug 2011 - 1:52pm
Diana Wynne

The trouble with always masking passwords is that it guarantees users won't remember them because they can't see what they're typing. Requiring them to reset, get agitated when told they've made a mistake, possibly abandon, and reinforcing that they don't remember the password or what they typed.

So they write the password on a postit, use something easy to remember (and hack), or save it in an even less secure email account. Passwords that users don't remember aren't secure except in theory.

Having a checkbox that allows users to display the password as they're typing is one way around this. Also if you must mask, mask after they tab to the next field or after a delay, so they can see the whole password instead of ***7.

1 Sep 2011 - 11:14am
Brian Mila


I disagree, I don't think its not being able to see the password (although that might help a little) as much as it is the number of distinct items to remember.  Every site that you register for requires two items, a user name and a password.   I can always see my user name when I enter it but I can barely remember my user name for this site, let alone all the other sites (linkedIn, fb, twitter, 3 credit card sites, cable tv site, wireless service site, local utility site, on and on).   If I can't even remember who my user name is, what chance do I have of remembering a unique, strong, password?   That is why people reuse passwords, its the one thing they can control (except for sites that have stronger pw checking, which then leaves me guessing, did I add 3 digits to the end of this one or did i need a special character).  The promise of SSO was never realized, and until it is, people will continue to reuse passwords whether they can see them on the screen or not, or like you mentioned, they begin writing them on stickies or worse, in a file on their computer.   Password managers are nice, and I use one myself, but it doesn't always work when you need to change a password (because the change pw form may be different from the normal login form), which again leaves me guessing until I lock myself out, or go straight to the 'forgot pw' link.


1 Sep 2011 - 2:25pm


Well said! I am currently consulting on the design of an account online product for a utility company. I have recommended (and backed up with references to Luke W's book) that we offer a hide password option and default to display the password. This made the IT folks nervous, but I've pushed hard for this feature.

Another consideration which is important in this password thing is personas and typical environments where people are logging in to your product/website/whatever. If the person logging into the product is a customer, chances are they are in an environment where they are with trusted people, or alone. Certainly, they will be aware if someone is looking over their shoulder at their password. Similarly, if they are in a more public place, they have the option to hide the password if they worry that some nefarious person is lurking about trying to see their password. Work applications are a bit trickier...there have been times when I'm projecting on a screen and even accidently started typing my password in the User ID field...and yup, everyone got to see the first three letters of my common password...again, hopefully there were no criminals lurking about that meeting room, if there were...I've got bigger problems probably...

I think that being able to see your password helps getting past the frustration that it is a typo that caused the password issue vs not remembering it correctly. I also completely agree that products that insist on certain criteria for passwords (to make them "more secure") cause more problems like Brian and others on this thread have talked about. My approach is make the password field as long as possible, and allow whatever characters (upper and lower case) a person can create with a typical keybord. That will allow the person to make a strong password that has the best strength, which is their ability to remember it.

Lastly, the irony is not lost on me either, as I had to create a new password to make this comment, since I couldn't remember my User ID! Again in my practice, even recently, I have requested that the User ID field be configured to accept an email address, and even promote that we do away with the concept of user ID and just use an email address instead. That way we usually collect a valid email address (needed for many applications - for password reset etc...), it is going to be unique and easy to remember. Even if you have multiple addresses, again you control which address you associate to each log in.

I think getting this process right is so important as it can be a repetitive irritant, and in some cases a completely broken welcome to the products we want these people to enjoy, feel safe and keep using. We should all work hard to get it right and to agree to some standard best practices, at least moving forward.


7 Sep 2011 - 9:27am
Brian Mila


To finish this one up (or beat it to death), what your proposing is reduce frustration by reducing security.  By displaying a plaintext pw you will allow the user to correct a possible typo at the expense of degraded security.  If you feel that tradeoff is worth it then go for it.  But personally I would default to not showing the password, because if I ever came across a site that didn't mask my password, I would have serious concerns about how secure that site really is.  Maybe some user testing could be done to find out if that approach has an impact on user's perception of security.  And just to throw a bone here, I probably would experiment with ways of progressively displaying the password rather than just exposing the whole thing to be viewed at a glance by anyone.  I might try either revealing each letter as the mouse passes over it, or perhaps a slider bar that slowly increases the contrast of the letters, or even something really crazy like converting it into a captcha-styled visual element and I would definitely fade it out very quickly so its not viewable for more than a few seconds.


7 Sep 2011 - 1:56pm
Dana Chisnell


  I totally agree with you. If it isn't usable, it isn't secure.

  Great techniques you're suggesting there.


7 Sep 2011 - 11:38am
Dimiter Simov

Has anyone tried or heard of replacing the password with a temporary access code? As I read through the thread I entertained the idea of not having a password in the traditional sense at all. Here's the scenario:

  1. Users register with their email address and/or phone number.
  2. When they want to log in, they enter the email address (or phone number) and click Log in.
  3. The system sends out an email (or text message) containing a temporary code that is valid for a few minutes.
  4. The user enters that code and receives access.

The code does not need to be something that no one can repeat, such as df45jw^W but can be a short memorable phrase or number; for example, beautiful weather or 998 1513.

For better security, the email can be encrypted, so only people who have the key will be able to read it.

I guess such a no-password approach will not be appropriate for sites storing sensitive information - personal data, money. It might work for a site as the one that Neil works on.

7 Sep 2011 - 2:01pm
Dana Chisnell


It's called a one-time password. This scheme mimics an RSA key, which a lot of people who work for large organziations use for remote access to at-work systems.

What if you don't have access to email for some reason? It could be sent to a phone. But what if you lose your phone?

Do you know anyone normal who can deal with public key encryption? It might sound nice, but you're actually compounding the problem because most email decrypters need to be authenticated to, too. :) Meta misery.



7 Sep 2011 - 2:05pm
Dana Chisnell


   I didn't mean to post this.

7 Sep 2011 - 3:06pm

For semi-masking, I've seen:

  • Passwords that show the character entered briefly before masking it on mobile apps
  • Options to show the password (for example, Mac wifi passwords - particularly useful since these are often long and random)

I understand that we have all grown to believe that masking passwords is part of security because of the danger of phishing, being observed, etc. But, there are situations where it doesn't make sense.

Also, I've heard, recently, a lot of non-visual ways to steal a password. My current favorite is one that measured the heat of the keys, and was able to crack a password entered on a public computer very easily.

To pile on to Dana's research with some comments from my own testing. In a general usability test of a form used (infrequently) by government funded researchers, we came across several people who NEVER remembered their email. They simply did "forgot my password" EVERY TIME they had to access the site. One of the problems was that the system requirements for passwords meant that they could not use their usual ones, so they simply couldn't keep track of one they use every 3-6 months.

There is a lot of "security theatre" out there.

I wonder, if you really do work with the security folks, you might find that their requirements are not as clear as they think they are. On another project, working through the rules for retrieving a password led to a much more humane process, as we were able to explore different user stories and use cases together.


7 Sep 2011 - 1:50pm
Dana Chisnell


   The problem with authentication is that it is an enabling task. Your IT people or CSO want it for account management and spam prevention. This automatically puts a burden on users. Basically, you're talking about a set of actions the user must take that are imposed on them and that are by their nature annoying because they come between the user and doing what they want to do with your site. All you can do in design is make those actions as close to not noticable as possible.

  If I were you, I would focus less on whether to mask or not and more on what the password requirements are.

  I've spent about 60 hours interviewing people about their mental models of password security over the last 6 months. Here are some key insights:

  • Authentication is never something that a user comes to a system, app, web site, device to do. It is an act forced on them by the organization offering the service they want to use to accomplish something.

  • Authentication causes interruption at three events:

      - on-boarding or registration
      - in on-going use when passwords expire and have to be replaced
      - when the user can't remember the password and has to have the password reset.

  • Most people didn't complain about registering, because it happens once and all the authentication events we were talking about were part of on-going use.

  • On the scale of security annoyances, registering is probably lowest. Password resets get the highest score for annoyance. Even quicky automatic resets.


Let's think about why this is. Passwords must be reset because people forget their passwords (fat-fingering counts as forgetting because getting the error message causes users to rethink whether they're typing the right password). People forget their passwords for two reasons: They don't use the password frequently enough to need to memorize it or write it down; OR the requirements for the complexity of the password don't match the personal password scheme they use everywhere else. This is why I suggest you focus on what the requirements for the password are more than the registering itself (although that's really important, too). If the password requirements are outsized-complex for the perceived purpose and usefulness of the site, users will just game the rules until they get through registration. In that case, the odds of whether they'll have to reset on next use are very high.

  You seem to be asking, "What's the sweet spot here? What is secure enough for the organization but won't piss off users?" And for this, I commend you. Not enough UXers are asking this. Unfortunately, those who are asking are mostly talking to one another. I urge you to talk to the person who makes the security policy in your organization. Get the threat models from that person. Use them like user stories and sketch for each one. Work with the security person until you come up with something that meets the minimum security requirements and doesn't break the user experience (and may even enhance the user experience).

 Good luck.

  In the meantime, you may want to poke through some of the research about password use and other security issues in the context of usability here: There's not a lot for you in the 2011 batch of papers, but previous years' papers (see the left nav) do address issues related to your concern.


Syndicate content Get the feed