Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Better Password Masking For Sign-Up Forms

Editor’s Note: This article expresses the author’s personal opinion and covers experimental UX techniques which aren’t considered to be best practice. Do you agree or disagree with the techniques? Can you propose better solutions? Let us know in the comments to this article!

Masking passwords is an old practice that’s commonly implemented in sign-up and log-in forms. It’s used to prevent over-the-shoulder snoopers from catching the user’s password. While masking passwords is a good security practice, there’s a chance it could jeopardize the user experience of your sign-up form. When users sign up on a website, they expect a no-hassle, worry-free form to fill out. But masking the password could prevent that.

Further Reading on SmashingMag: Link

Good For Logging In, Bad For Signing Up Link

Log-in forms are used more often than sign-up forms. Users only need to sign up once to create an account, whereas they will need to log in multiple times to access their account. Because log-in forms are used so frequently, there’s a strong chance that users will end up typing their password in front of other people. Users sometimes want to show their friends or colleagues something on the website, and they would need to log in to do so. Therefore, masking passwords in log-in forms is good because it keeps passwords hidden every time the user logs in.

However, masking passwords in sign-up forms is different. Password masking generally causes users to make more typing errors because they can’t see what they’re typing and can’t tell whether they’ve made a mistake. The consequences of making a typing error when logging in are not as serious as making one when signing up. If the user fails to type in the right password when logging in, they simply try again. If they type in the wrong password when signing up, they’ll get locked out of their account when they try to log in and will have to reset their password. The user isn’t to blame when this happens. It’s the designer’s fault for not making it easy for the user to see what they’re typing in the password field.

What If We Omit Confirmation Fields In Sign-Up Forms? Link

A big hurdle that password masking creates for users is the password-confirmation field commonly found in sign-up forms. This field requires users to retype their password and checks that both match so that the wrong password doesn’t go through. The reason why password-confirmation fields exist is that users sometimes make typos when typing their password with masking on, and this extra field can catch those typos.

Password Confirmation Field

Password-confirmation fields might be well intentioned, but they have a downside. Users are prone to making even more typos because they have to type their password twice in separate fields with masking on. What’s worse is the extra work they have to do to correct their typos; because they can’t see where their typos are, users have to clear the fields entirely and retype their password. The password-confirmation field not only causes more typos, but forces users to do more work to fix them, thus slowing users down and making sign-ups more of a pain.

Unmasking Passwords Temporarily Decreases Typos Link

Masking passwords in sign-up forms might give users more trouble than it’s worth. It masks not only the password, but any typos the user makes, making them hard to spot and fix. The security it provides is often less than helpful because many people usually sign up for websites in private, with no one looking over their shoulder. Signing up is usually a one-time deal; once they’ve done it, they don’t need to do it again. Displaying their password in plain text that one time when they are alone is probably not as a significant security risk as we tend to think. The chance of a snooper catching the password is slim to none, even if the user is signing up in public.

Typing Masked Passwords

The solution to all of these issues is to temporarily unmask the password so that the user can fill in the field quickly and accurately — i.e. unmasking the password for a moment so that the user can see what they’ve typed. Temporary unmasking decreases typos and makes it easy for users to catch and fix any typos they make. And the user doesn’t have to worry about snoopers stealing their password because the unmasking is quick, e.g. if we unmask a couple of last characters typed in. Snoopers would have to memorize a string of (hopefully) random alphanumeric characters in a matter of seconds, which is very hard to do. If we unmask only last characters, they would need to look over the shoulders for a longer period of time to be able to “catch” the whole pass phrase.

I strongly believe that a lot of the snooping paranoia is in our minds — the bigger issue is users getting locked out of their account because of typos caused by masked passwords. Below are a couple of simple techniques to prevent that from happening.

Unmasking on Field Focus Link

You can make the password field easy to fill in and secure at the same time by unmasking the password when the keyboard focus is on the field and then automatically masking it when the focus is off the field. This allows the user to see the characters they’re typing only when the password field is selected, thus decreasing the risk of typos and preventing others from sneaking a peek when the user has moved on to other fields.

Masking- Field Focus

Another small security measure you could add is to display the user’s password in small, light-gray italicized text. Thus, being able to make out each character would require moving close to the screen. In the unlikely event that a snooper is looking on, the modified text would make the password indiscernible to everyone except the person sitting right in front of the screen.

Another option would be to display only the last characters of the password while hiding other characters with asterisks, thus confirming the user’s input as the password is typed in.

Unmasking With a Checkbox Link

Another approach is to provide a checkbox for unmasking. Thus, when the user types their password, it is masked, but when they check the box, it gets unmasked, allowing them to see whether they’ve made a typo. A little more effort is required with this approach with the checking and unchecking, but it’s far better than a password-confirmation field because it enables users to see and fix their typos with ease.

Masking Checkbox

Balancing Security And User Experience Link

Following design conventions is generally advisable, but when a convention slows users down, complicates a task or increases the chance of error, it needs serious reconsideration. Security should be balanced with the user experience. Favor security too much over the experience and you’ll make the website a pain to use. Favor the experience too much over security and you’ll make visitors nervous about using the website. When you find that balance, users won’t have any trouble using your website, even if it doesn’t adhere to every design convention.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4

↑ Back to top Tweet itShare on Facebook

Founder of UX Movement, an online magazine for learning user experience design. Creator of Wireframe Patterns, a pro wireframing toolkit & Flow Patterns, a toolkit for making visual site/user flows

  1. 1

    I disagree. I’m so used to typing obscured passwords that I wouldn’t be able to quickly recognize the letterforms if my password were un-obscured.

    I think signup forms should do away with the password field entirely and allow users to simply enter their email. Then they could be emailed a unique link which allows the user to access the site and set their password.

    • 2

      Uugh! More workflow to do something simple is not the direction to go here.

    • 3

      I fully agree with your first statement. I personally would find it harder to recognise my own password than simply retype it. However your second statement is ridiculous. You’re now stepping away from the UX aspect of the article and looking solely at the security argument. Of course your suggestion of emailing a temporary password and being forced to change it is secure, but it is highly disengaging, time consuming and pointless for majority of websites.

    • 4

      I have to agree here with Wayne, even if it is not fully the point of the article.
      In some cases the form is a serious friction point s.t. potential new signups could actually be lost (users refuse to invest the time/effort to signup). In such cases something like quick like username + email to create a temp password could be a solution – granting site access asap to new users.

  2. 5

    This is a fantastic way to rethink the password field. Give the user the choice of viewing it masked or unmasked puts the power of the level of security in their hands. I’m curious what your take is on doing this the way the iPhone does when typing in your password, showing each character temporarily until the next character is keyed. Do you think that convention wouldn’t translate well to a desktop browser?

    • 6

      Windows 8 uses a small eye icon in the password box for this – when held down the password is revealed. It works really well, for registration and for login if you think you might have made a typo.

      • 7

        Held down, now that would be a good idea, except that it is (by definition) kinetic — meaning that it is not accessible for those with cognitive or motor impairments.

        The most obvious tool for making the feature accessible to those users would be persistent focus. Unfortunately, this approach is in direct opposition to the point of persistent focus, as it would cause the password to display… persistently. ;)

        Hmm. Maybe something like this:

        * trigger the password show when the button is held down
        * revert to masking the password when the button is released

        * trigger the password show when the button gains the persistent focus (for accessibility)
        * revert to masking the password when the button loses the persistent focus (blur)

        * as a backup, timeout the password show so that it reverts to masked after a short interval

        The timeout prevents the persistent focus being accidentally left there, showing the password. It also helps out if the button press event (be it a key press, click and hold, or tap and hold event) gets stuck (or one of them does).

        Do it similar to that and you’ve both made it more accessible and more secure at the same time. I’m all for innovating, so long as there is a good backup plan.

    • 8

      I guess that pattern could work fine also on desktop, but I think it’d be a little less effective, since typing on a physical keyboard is usually faster than typing on a virtual one. And above all, most people look at the keyboard when they’re typing (not at the screen), making the pattern completely pointless.

      Another good approach (IMHO) would be including the “show password” checkbox, but checked by default. This way, if I’m alone I could check my password without concerns for security, or if I’m not I could uncheck the box and type my password.

      What do you think?

      • 9

        It should be exactly the opposite.

        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 honored only *very temporarily* before reverting to masked.


        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.

        This is especially important when your agent sees a threat that you do not, because you are distracted or otherwise ignorant of the consequences of a particular course of action (or inaction).

        A good implementation would, by itself, revert the interface to displaying only the masked password after a few seconds of inactivity (no keystrokes). It would assume you have become distracted or have finished entering the password. Think of this as the same thing as a bodyguard snatching you back onto the curb instead of getting hit by the bus you didn’t see coming.

        For the password field, if you begin typing again (or, otherwise, explicitly switch off the masking again) then the plain text is again displayed until the next bout of inactivity. No harm, no foul. You can now cross the street like you were going to do.

        Getting out of your way when you tell it to is one thing. Waiting for the person you are trying to protect to *tell you* to keep them from getting hit by a bus is as absurd as if the person then actually stepped off the curb. It’s like the punchline to a situational comedy sketch.

        Do what you think is right. But, don’t you dare sell your charge down the river just because they like boat rides.

        • 10

          Also, if someone has to explicitly show the password with a button or something, it is likely that they will take stock of their surroundings as part of their decision process before committing to the act of unmasking the password.

          If it is shown by default, you are going to shock the new sign up, as they will:

          (1) expect the password to be masked
          (2) freak out that their chosen password is either partially or fully visible *by the time they look up from their keyboard to notice it unmasked*

          Then, after freaking out, they will either have to:

          (1) mull over a new password to use, which slows down the sign up process, twirks them off about your site, and gives them something to tweet, something to blog, and something to hold against you
          (2) despair because they use that same password for everything and — wouldn’t you know it — that creepy guy in the next cubicle *did* happen to be looking over here this time…

          Here’s your M.A. in Blindsiding Your Users. Congrats!

          • 11

            I agree. This is something that less experienced computer users would lose their heads over, I can picture a conservative office worker getting pissed. I think they typical enter your password twice deal is fine for everyone. If you don’t know how to type your password correctly twice, then you should get off of a computer!

    • 12

      I don’t think users would use (or even understand the point of) the “Show password” check box. It’s a great option, but I don’t see it being used much. People on the internet are all about speed (especially when filling out forms. No one likes to do that), and a check box would just slow them down.

      However, I do like the iOS style of showing the last character for about 2 seconds before it turns into a bullet. For added security, it could be a grayed-out italicized letter like in the article. I can see this showing up in OS X some time in the near future.

      Another option would be to only show the passwords when they don’t match. Or provide the option to show them (check box or yes/no question). That might work. What do you think?

      • 13

        Oh, for the love of Pete.

        Repeat after me… There should *never, ever, ever, ever* be a time where the form automatically shows *any* portion of the password field. Ever.

        Showing the passwords when they don’t match? Really?
        What would be the point of that? Whether it matches or not is irrelevant – the system will not accept the mismatch either way. So, what? Are you showing the password fields just to prove to the user that they messed up? Is the goal to throw it in their face while adding injury to insult by revealing the password fields to any onlooker?

        I mean, forget that one or the other of the fields probably contains the correct password in all of its naked glory.
        Forget that the combination of the two fields most definitely lets the intended password be interpolated.

        No, let’s make darn sure that the user can’t just clear the fields and try to use *the same password* again — that would be too convenient

        Instead, we must put on our little engineer’s hat and assume we know better than the user about what they need. After all, people *want* you to show their password in *all kinds of situations* just because you can!

        WHY do people keep coming up with ingenious ways to show the password *without user intervention* before having first proven any need to show the darn thing in the first place?

        IF someone needs to see the password, then they have ample motivation to press a button to make it happen.

        • 14

          The point is that the user doesn’t want to have to take the extra time to retype each password, and maybe even again after that. The user wants to see where he/she messed up and fix it. Another thing too: if the user sees his correct password after a correction, he’s probably more likely to remember it (though that’s not really the point of the article).

          And besides, how often do people create accounts in public? And if they do, how often is somebody staring over their shoulder to see the username and the 3-second revelation of what the password is? I don’t think very often.

          • 15

            “The point is that the user doesn’t want to have to take the extra time to retype each password, and maybe even again after that. The user wants to see where he/she messed up and fix it. Another thing too: if the user sees his correct password after a correction, he’s probably more likely to remember it (though that’s not really the point of the article).”

            It is yet another example of some so-called UX expert over-analyzing minutia to arrive at a net detriment to the user themselves disguised as an improvement to their “experience.”

            The point to which you refer is not a point that matters when compared to the functional imperatives.

            The point of the sign-up form is not to impress the user with its ease. It is to let the user obtain an account.

            The point of the password is not to make the user jump through unnecessary hoops. It is to facilitate the user having exclusive access to said account.

            The point of masking the password in the first place is not some arcane purpose lost to the mists of time. It is to further facilitate the user in maintaining exclusive access to said account, because the user potentially suffers if said account is compromised by someone else getting a hold of said password.

            The point of not programmatically showing the password without the explicit directive of the user is not one that is merely academic or arbitrary. It is that you are otherwise making a unilateral decision to jeopardize the aforementioned exclusive access — thereby rendering moot the point of having said password and perhaps even said account.

            My point — and the counterpoint to that which you note — is that *it is not rightfully your exclusive decision* because *you are not the only one who suffers* the consequences of a compromise — the user is also put at risk.

            So, again, IF someone (a.k.a. the user) needs to see the password, then they have ample motivation to press a button to make it happen.

            If, on the other hand, *you* do not wish to risk suffering on your end, then you can simply not provide a means for the user to unmask the password in the first place.

            “And besides, how often do people create accounts in public? And if they do, how often is somebody staring over their shoulder to see the username and the 3-second revelation of what the password is? I don’t think very often.”

            Well, we could debate how often. But, then, that is the point.

            And, with all due respect, it would be irresponsible to the user to speculate as to their environment or state of mind when using the sign up form. You haven’t researched usage scenarios, don’t have the data to back up your hunch of “I don’t think very often,” and — above all — it is the purest folly to presume to know best when you know nothing.

          • 16

            If a user “messed up” their password, they likely do not know where the error was, or they would use backspace or select all and delete, then start over.

            You are right that users do not want to take the time to retype their password. I agree with Ray that if a user NEEDS to see their password, they should make an effort to click said “show” button. Google Chrome follows this pattern in their Saved Passwords tool.

            The method Apple uses to show the last typed letter for 1-2 seconds after works well because you never see the entire unmasked password.

      • 17

        Yeah – I think it’s a nice idea to include a “Show my password” option in the error message.

        So if the user inserts different passwords and a error message pops up on the right-hand-side of the password fields, he has already lost his workflow – he would take the time to recognise everything inside the error message box. And so it’s more likely that he would use that feature.

        If he inserts the right password two times, then he wouldn’t even need this feature because then would’t read his inputs, he would just type fast without reading.

  3. 18

    Disagree. I’de never click “show password” with someone standing over my shoulder, so I’de be at the will of typing my password correctly the first time. Why not add a checkbox to the second password field that says “Skip this, I’m always right” instead?

    Anyway, do away with sign up forms and use a 3rd party authentication service.

    • 19

      “Skip this, I’m always right” – I need this button for everything :p

    • 20

      I think the point of the article is that realistically, there is rarely — if ever — a person standing over your shoulder when you’re creating a password. I for one cannot think of a single time where I needed that level of security when creating a password. Do you find that there are always people standing behind you, trying to steal your passwords? Is it time to find a safer neighourhood perhaps?

      • 21

        I can think of plenty of screen sharing instances where someone has to log into something while others can see what they’re doing. Agreed though… who watches over shoulders anymore?

      • 23

        I’m with you, ill people behind my back are not my nightmare..

      • 24

        I often sign up for things recommended to me infront of friends / colleagues. Granted these are not exactly the kind of people likely to steal your details for malicious intent, they could however very easily fall into this category one day.

    • 25

      I’m with Michal on this one, 3rd party auth should be the future of sign up processes. With nearly everyone having a Twitter, FB, G+ or LinkedIn account there’s no need for them.

      • 26

        But what of I have a Facebook, G+ or LinkedIn account and don’t want to use it because I don’t want to give them even more info about myself. Third-party sign-ups are a great feature, I’m just concerned about privacy.

        Also, as I write this, I staunchly refuse to hand over my information to Facebook or G+ and thus are not even a member. You can’t just discount an entire segment of the population.

      • 27

        Um. No.

        Reasons third party authentication does not remove the need for direct authentication:

        1) The third party can only be as trustworthy as you are, because you are providing the information to the third party
        2) The third party can not be as trustworthy as you are, because they have their own ulterior motives for offering the authentication service which may, at some point, conflict with your interest or that of the second party
        3) The third party is not trustworthy at all, because history shows that they will actively plot against your interest for their own gain
        4) The second party (like Hulu) doesn’t care that you signed in via the third party (like Facebook), because its a phish for data about you and not an authentication — the second party still makes you sign up and create credentials
        5) The third party can never become mandatory, because (a) there are too many third parties; (b) they are in competition, and so will work for exclusivity (Coke vs. Pepsi at restaurants); and (c), even if you did manage to make third party authentication standard, you will have created a market for an alternatives (people sick of the third party authentication services)
        6) The only reason to leave it to a third party is that you are not considered trustworthy… so I have to think this angle of “3rd party auth should be the future of sign up processes” is serving the interest of the site or third party, not the interest of the account holder — which is backward and just proves the point that others interests will be put ahead of the user
        7) Forcing one to have an account with one site to have an account with another is collusion. If one of the sites were commercial in nature (ahem, all of the social services you mentioned), it would be unlawful. It’s creating a monopoly situation which causes harm to competition. It’s on the same level as price fixing and torching the store that didn’t pay the protection money.

        I, for one, would love to have to pay a Facebook tax in order to even have a store online, because everyone uses the FB sign-in and FB can, therefore, charge a fee to the site for the privilege of using the mandatory-if-ya-wanna-do-business service.

        I can hear Google now in response to not using their Google+ social log-in racket: “It’d be a pity if your store’s PR were to have an accident.”

  4. 28

    Couple of things:
    Is there any data to support your claims (users making misstakes etc.)?

    There is a possibility users won’t deem the sign up forms secure if they type their password and can see it. Often people sign up with their friends or family for accounts – I am sure they don’t want their password seen. Checkmark to show password would be a good option in this case, but by default it’ll have to not show the characters.

    There’s also another option: showing only the last character typed (even then, timed) a la iPhone style.

  5. 29

    I would strongly argue against your suggested approaches.

    1. Simply displaying the password field is very uncommon behaviour, it instantly creates cognitive dissonance and perhaps even instant panic as your “secret” password is displayed for all on lookers. You may worry that your password will be visible in all places within the application and may even make you change your password to a less memorable one.

    Although it would not impact on all users I suspect that the average time to complete registration may take longer with the one time only, revealed password, rather than the hidden 2 passwords in a real world rather than an observed test.

    2. Temporarily hiding passwords. I would be very concerned that the code would conflict with a mobile devices keyboard behaviour and lead to autocorrected passwords or weird focus behaviour.

    3. Reveal with checkbox. Probably the best option, but I suspect this is may to lead to more incorrectly typed passwords than forcing double typing, certainly it would require A/B testing on a live site to determine this as it is certainly not a clear cut case.

    Typing your password in twice allows you to make sure you pick a password which can be typed easily, which helps with the common user experience of typing in a password versus the one time only create your account.

    The main problem with registering is CAPTCHA. Improving / removing this aspect will be a huge improvement where as changing password behaviour as you have suggested is at best a minor improvement and at worse could actually hinder UX.

    • 30

      Agree, but i strongly believe that “password revealing” have no use in practice. Just as it always happen to wild theories when they meet the reality. There’s no spoon, you remember?

      1. In the first place, how do i actually know that i my password is incorrect? Otherwise i don’t have any reason to show it. Gongratz, your simplification just forced me to use password recovery!

      2. If i suspect that something is wrong with my passwd, i’ll just clear the field and type it again. Simply because it takes much less actions and time than trying to correct, because:
      1) People type fast.
      2) People usually use both hands to do it.
      3) People move to next form field or element by using their keyboards. The magic “tab” key.
      4) Lots of people have no idea that they can move to previous field with secret ninja “shift+tab” jutsu. So, they’ll be forced to grab their mouse to go back from checkbox to password field :)
      5) Try to imagine, how long it will take you to find typo at passwords like one of mine: 15XftrDghjdjlf[? Compare it with 1-1.s of time required to retype it. Make conclusions.

      Resume: if i need to choose between two password fields and minor but potentially harmful simplification, i choose two fields.

  6. 31

    While good intentioned, this article seems to make a lot of assumptions and speculations before suggesting compromising security.

    Assuming people only sign-up for something in private is a big assumption. Perhaps with large sites such as Facebook and alike this may be the case, but so many sites require a sign-up of sorts that to assume they would only ever be done in a darkened room seems a folly. By actively showing a password, I would suggest you are almost forcing people to sign-up in darkened rooms. Perception is key.

    I’ve also never once heard anyone complaining about having to ‘confirm’ a password. Much bigger a source of frustration are the almost indecipherable Captcha devices.

  7. 32


    October 26, 2012 6:42 am

    Comments above mine have clearly indicated what the first and foremost pitfall to this opinion is. Users are very much used to seeing masked characters in the password field and it has a led to a subconscious feeling of security.

    Now if you happen to give them unmasked fields as they enter the password, the triggers from years of seeing ‘masked’ password fields would make them “think” that the web form is unsecure. No data goes with this claim but it’s a simple case in point.

    The present method of double password with Ajax scripting pointing out if the retyped password matches or not is good enough. I mean look at the demographic of users that sign-up. We’re moving into a period where most users are comfortable with that type of a sign-up process. It’s an optimal situation for both users and developers.

    Just because there’s a slight instance of extra effort or “purported” obtrusiveness does not mean we have to immediately attack the processes. This is the result of being fetishly in love with usability. It’s not “wrong” to make users be cautious, careful or do a little work.

    Let’s not make users think “less” in this mad race to ultra UX ideologies. UX should “enable” and “simplify” but not at the cost of turning off users’ brains.

  8. 33

    Interesting idea. I think unmasking with a checkbox would be the only way to go because if I was sat with someone as I made an account and I typed my password (expecting it to be masked) and it was shown in plain view, the other person would know it from only a glance. The user needs the control because they will be expecting the convention that password fields are masked.

    The “Show my password” checkbox is typically used on wireless connections for security keys.

  9. 35

    Displaying the last character entered briefly is becoming an expected experience as things shift more to mobile. I’d lean towards this, with an option to reveal password incase the user felt they hit a few wrong keys. Its obviously a sensitive area. Acceptability will depend a lot on the type of information the user will store in the application.

  10. 36

    All of these ideas are good…having said this I’d tend to agree with a lot of the comments. There is a lot of energy on the password field and in my business (U.S. Financial industry) we are highly audited and have fairly rigorous standards under the guise of “security”. At our company, we are basically required to everything on the “maybe not” list…and when we’ve attempted minor modifications like “check to unobscure password” or eliminating the 2nd password field, we fail security audits and releases are held and brown stuff hits the fan. I personally am a fan of what one of the comments say which is when registering, all I should enter is a username and email address. Then a temp password is entered, I login with that and am forced to create a new one, which I generate randomly myself (happen to use 1Password but there are plenty of other ways). I see no reason to enter it a second time in this scenario. But the world says it should work the way it does now and maybe it’ll change someday…

  11. 37

    Fabio Schenone

    October 26, 2012 7:15 am

    Super nice !!! I always wanted to try something like this … but I was too lazy to code ;)

  12. 38

    I can’t agree with Chandrashekhar because that’s not entirely true anymore. Next time you use your phone think about the several ‘security’ checks you fail on every time due to the nature of the task and the device itself. Some of us are gifted enough to be able to type at high speeds making it harder for someone to register what is physically typed, however the majority of the population type with single digits.

    Not only that, but on a mobile or any tap device, the key pressed is always shown on screen regardless of the type of field because of the nature of the device mechanic. regardless of device, we are always physically showing what our password is, whether in private or public.

    There is another school of thought which is becoming more widespread which is to do away with the genuinely unnecessary repetition. You’re going to get an email address off them, send them confirmation of the credentials, it’s not more or less secure. Same goes for the email field, stop making me type the same thing twice, I’m not a typist, I am a browser of fine antiquities.

    I don’t think we need to resolve the password or security issues at all, what we do need to resolve is the obscene amount of time it takes to create accounts on any system due to double entry. If I mucked up something – just let me fix it in a simple way, don’t keep adding roadblocks.

    • 39

      I’d like to see the data that backs up your claim for majority of the population typing with single digits. I agree this may have been the case 10 or even 5 years ago, but I would say that in this day and age, a lot more people are comfortable typing at regular speeds especially in first world countries.

      The point of retyping things is to stop muscle memory typing mistakes. You say “If I mucked up something – just let me fix it in a simple way, don’t keep adding roadblocks” but the reality is, we usually type passwords and email addresses as quickly as possible, through muscle memory reflexes and don’t usually rely on reading what we have type. Typing it out twice isn’t much extra hassle for a heavy user, and it alerts the user of any mistakes they have made without forcing them to read over what they have typed character for character.

      • 40

        Hi Kelly,

        Big sorry, i’m completely with you but clicked the wrong button and vote you down, couldn’t make it backwards… bad usability ;-)


  13. 41

    Seriously, who are all these people standing over everyone’s shoulders?

    “I strongly believe that a lot of the snooping paranoia is in our mind”

    I totally agree with this. I mean, unless we’re talking about online banking or the like, what is the big deal with displaying the password when you’re creating it?

    • 42

      People are using computers in public settings (coffee shops, libraries, classrooms, trains, etc.) even more today than they were 10 years ago. While you probably don’t have binoculars trained on your screen in these situations, it’s a good idea to assume that someone may be watching what you type.

      If the wrong person is watching they may actually go through the effort to not only get into that account, but to try your email/password combination on other sites (Facebook, Gmail, etc.) and try to further infiltrate your identity. Since many people tend to reuse passwords across multiple sites, this is a real threat.

      I like the opt-in approach presented here since it allows users to make their own decision about whether they’re working in a safe location. However, I would recommend the text next to the unmasking checkbox read “Show my password, no one else is watching” to remind them why they might not want to check it.

  14. 43

    Question: I liked the idea of showing the password when the field is focused. Can you achieve that with CSS? or you need JavaScript?


    • 44

      Hi Tedel,

      It can most definitely be done with CSS. Just use the :focus psuedo-selector and transform the text that way.

      Here’s an example:

      • 45

        No. No. No!

        The CSS is only involved with positioning, hiding, and aesthetic. It will not mask or unmask the password!

        You need script to:

        (1) sync the value of the <input type=”password”> with a hidden <input type=”text”>
        (2) swap the <input type=”password”> out for the <input type=”text”> when showing the password
        (3) sync any changes from the <input type=”text”> back to the value of <input type=”password”>
        (4) swap the <input type=”text”> out for the <input type=”password”> when masking the password again
        (5) destroying the <input type=”text”> when the form submits

        Oh, and don’t even think about revealing the password “on focus”. The user will never be able to type in a secure way. Make it a button or checkbox. Make it toggle between show and hide. Make the show state time out and revert to hide state a few moments after the last keypress.

        • 46

          @Ray – Your solution is a bit messy, you can easily change the input type of the field with JS rather than having a second hidden input field.

          • 47

            The pattern I presented is commonly implemented, and is not *my* solution.

            The same pattern has been used for a while now to implement “pretty” forms cross-browser and cross-platform.

            Further, it is not even a comprehensive solution. It is an example of the steps needed to cogently handle passwords being show and hidden in a way that will almost certainly work in all browsers and on all devices that implement scripting.

            It may seem like overkill. But, it is, in fact, robust. There is pretty much nil chance of collateral consequences due to the browser or platform throwing you a curve ball.

            Changing the type of the original password field is wrought with uncertainties. Do you know for a fact that changing the type of the original field will not reset its value to empty in some browser? Do you know for a fact that you will be able to even change the type of the field with certain security add-ons and security suites installed on the target computer/device? Even if you can, will it throw up a security warning, making your site look suspicious and insecure to the user?

            Messy? Perhaps. Does it work? Yes. Can it be done with only CSS (the original question)? No.

        • 48

          You can create a font which consist only of “*” chars (each character looks like a star or something) and change the font for focused fields.

          However I have another solution for the main problem: for registration give the form with email and password fields (1 masked password) and provide easy password reset (which should be done anyway). Isn’t it simple and secure?

          • 49

            Hi Jack.

            There is a huge problem with relying on a font which merely displays all of the password characters as asterisks. The password field would then (presumably) contain the actual character codes for the corresponding typed password characters within the character set.

            This means that, in certain scenarios, their readable password will be displayed with no obvious way to turn it off! This can happen if a user has their browser set to override a site’s choice of fonts, or if they have a custom stylesheet — either of which may be due to necessity for accessibility.

            Simply replacing the character glyph does not replace the character code. Changing fonts simply maps the character code within the character set into the appropriate glyph in the target font. It would be about as secure as relying on being able to set the font color to the same as the background color.

            Proper password field implementations in browsers actually populate each character in the password input box interface itself with the masking character, as the box is only a feedback mechanism. The actual typed character codes are stored in the DOM as the value of the input element.

            Regarding the alternate solution you propose, you are on the right track from a functional and security point of view.

            However, it does not eliminate the “inconvenience” to the user if they mistyped the password on sign up. It merely provides a tool to overcome the problem. That makes it unsuitable to the “problem” which the article is prioritizing over what it contends is a tiny enough risk that we should reconsider whether we, as designers/developers, can just decide to take that risk in exclusion to the will of the user (for their benefit, of course).

            On a side note, from TFA: “Security should be balanced with the user experience.”

            That is nothing short of a grossly self-serving UX-centric point of view. It is like saying we should compromise safety so that something looks pleasing. Do the world a favor and don’t build anything important if you subscribe to this school of thought. Your victims — through your indifference to their welfare — will not thank you for your “improved experience.”

            Look, *nobody* whose password gets stolen due to you doing one of these half-thought-out “experience-enhancing’ implementations will come back and tell you it was worth it to not have to type the password twice. And, they will especially sue — I mean, like — you if you don’t give them a choice.

      • 50

        How does that mask or unmask the password? Your example only changed the color. I can see it changing the font to bullets or something, but you can’t really control that via a user option, just on focus.

  15. 51

    Now if only I can get web page designers to stop asking me to type my email address into sign up pages twice. I just don’t see the point, I always cut and paste it the second time.

  16. 53

    Browsers don’t cache password input fields for use on other sites in autocomplete data. They DO cache other text fields, so anyone using the same computer would be able to easily determine the password by typing a couple characters in a text box on any other site.

  17. 55

    People often advocate that masking the password is just good security on a sign up form but I think of all the use cases where someone’s account was hacked – having the devious criminal retrieve the person’s password by peeking over their shoulder at the moment of their signing up for an account is pretty darn low on the real world plausibility list.

    In actuality, most password break-ins are the fault of the programmers through either allowing users to use dumb 1234 type passwords that can be easily cracked by brute force or by elementary security faults like keeping passwords in plain text – there’s at least a story or two every month about this kind of situation.

    • 56

      Scott, you’re right. But, it’s not *merely* the silly passwords or keeping passwords in plain text.

      It’s the fact that you’ve got social engineering from both sides *and* the security theater performed by idiots who have no idea how to deal with the social engineering, but feel that they must “do something.”

      The social engineering is the real biter. It’s the tool of choice for anyone serious about getting one over on anyone else. This is because everyone in a society puts a certain degree of trust with their vitals in the hands of others. To a certain extent, this trust is extended out of necessity. But, unearned trust occurs a lot as a matter of courtesy or respect.

      Most trust that someone will not hit them when they cross the street.
      Most trust that cross-traffic will stop when it’s green their way.
      Most trust that the doctors at the emergency room are not going to be incompetent or sadistic.

      Though, sometimes that trust falls on its face and people do get hit crossing the street, or t-boned in the intersection, or messed up by a doctor. It’s just that it is infrequent enough in one’s personal sphere that it is not, in the least, expected — even though we all reserve some apprehension for the consequences of being wrong.

      Social engineering tactics focus on making things seem normal, right, calm, and at-ease. They are specifically designed to overcome your apprehension so as to allow your trust bonds to take over.

      This is what most big data compromises — like credit card numbers and bank account access details — exploit. The successful endeavors aren’t hacking a zillion 1234 passwords or randomly probing public-facing systems. They are trading in knowledge of vulnerabilities — knowledge obtained through social interactions with someone on the inside or very near the potential mark. The password cracking and port scanning and probing and compromises all come afterward — testing the validity of the information, checking for traps/honeypot environments, planting tools for later use, and a thousand other concerns.

      Most hackers do not — certainly not the successful ones — sit there and try brute-force cracking passwords. Wisdom will dictate that it is much more productive to learn how to break the guard that checks the password.

      Also, frankly, the characters involved in a password don’t matter — it’s the frequency of occurrence within the available set and the length of the set that determines the relative security of a password. Most of these password policies are counter-productive security theater, plain and simple.

      I want to know the pattern of a password for a given site. So, I just go to the sign-up form and look for a way to get it to reveal the password pattern the site accepts. Now their “first character is a letter, use at least one number, no spaces, minimum 6 characters, maximum 32 characters” policy has just made cracking a password easier. Why? Because they limited the number of possible combinations… exponentially.

      Brilliant move.

      It’s not that a person chooses a simple password, its that the constraints to the password’s form is simple, and thereby allows for any combination within those constraints to be insecure.

  18. 57

    Michel Parpaillon

    October 27, 2012 5:46 am

    A nice alternative could be to add a small button just aside the input which shows the password unmasked only on “mousedown” and mask again on “mouseup”.

    Why do you think ?

  19. 58

    I don’t see anyone mentioning that the checkbox option may be a security risk if the user leaves his computer for a second before submitting. Maybe even after submitting, if the data is still there when going back in some implementations. An onlooker could quickly click “show password” and steal it.

    Others have mentioned the unmasking-while-focused option could surprise users when others are looking. Users could’ve used the tab key on their keyboard and never looked at their screen while typing.

    Any fixes I can think of for these issues just make it more confusing for the user, when they’re just expecting to type and submit.

    If you want to make signup forms more usable, use easier captchas and simple yet secure password rules. Something akin to “Choose three or more words as your password” instantly increases both security and the user’s ability to remember a highly secure password, I believe.

    • 59

      Yes, letting users do things on their own is a security risk. But, you can’t cure stupid.

      How exactly would one go about mitigating a user potentially getting up from their desk while something security-critical is happening? Wouldn’t the mere existence of the form itself be a security risk? I mean, a user could potentially shout out each of the characters as they type it in!

      Too bad all users are easily confused morons. Best to not even let them see your site.

      Quick! Take it offline before it’s too late!

  20. 60

    I think this could be a security risk as if they leave there computer while the sign is in process someone to could click on the password field and unmask it. But what I think should happen is this when they type a letter that is not hidden the when they type another the one before masks and the one you just typed is unmasked.

    Do you see where I am getting at?

  21. 61

    passwords have been masked ever since, oh I don’t know FOREVER. I think users are used to it by now and understand it’s for their own security. I would be perturbed to see my password isn’t being masked.

    • 62

      General Lee Correct (ad-libbing the good doctor to drive the point home):

      [Surgeon’s faces] have been masked ever since, oh I don’t know [WE STOPPED POURING OUR CHAMBER POTS OUT ONTO PEOPLE IN THE STREET BELOW]. I think [patients] are used to it by now and understand it’s for their own [health]. I would be perturbed to see my [surgeon’s face] isn’t being masked.

  22. 63

    Security does have a higher precedence than user experience. And your techniques are far from good.

    If you do not want users to make mistakes with their passwords, then simply only ask them to fill in the email; send them a confirmation mail with a password, and tell them to change their password afterwards.

    Then the user is already signed up and you have his email address should the user ever fail to login regardless whatever his current password is. This allows a user to reset their password.

    And logging in with masked passwords is not a bad user experience. Users are allowed to make mistakes and retry. Even if people try to bruteforce, which is not very common for Login systems and also easily detected. The user is still the only person with access to the Email address. And if he is not, it is far easier to reset and steal an account, then it is to bruteforce your way into a system.

    Based on your articles on Security + UX alone, I would never hire you because of your bad take on security. And I hope in the future SmashingMagazine rethinks about publishing articles like this.

    • 64

      You da man. Word.

    • 65

      I agree that the approach of having them verify their email first and being able to use password recovery is nice, but after this you still have the user typing a password in that they may mistype.

      There is a learning curve to password memorization. Having users repeatedly enter the password and providing visual reinforcement can help them remember it faster. This is even more important if they are choosing a complex password with mixed case alphabetic characters plus symbols and numbers.

      I don’t think just leaving passwords masked during enrollment is a terrible practice, but it is fair to ask if there is an advantage to providing users with an unmask option. And to ask if this is an acceptable security risk.

  23. 66

    I feel this article has been entirely written on a perfect-world basis, and is not taking user’s habits (which have been developed over years of using password inputs) into account.

    I personally wouldn’t be comfortable reading my own password. I would say that I have honestly never seen my password typed out in full, character for character. It would feel uncomfortable and unnatural for me to read my own password. I only know it as a series of keys I press, in a certain order, in a certain way. I believe this is what a password has become, more so than an actual string of legible characters. It would take me longer to read through my password to ensure all characters were correct, and in the correct order, than to simply retype it. I think the UX of double typing a password string is much more effective than having the user manually check to see if their password is correct.

    I would be open to seeing some data analysis to argue this point, but I feel we’re somehow stepping backwards here and not giving the users enough credit to what they have become accustomed to and now expect.

    • 67

      Seriously. The only time I’ve needed to unmask a password so I could see it — where it was unworkable or a pain in the rear to reset it and subsequently change it to a known value — was when the password being shown was for something like FTP or database access — something where the system sets the password or the login credentials are also used programmatically, and, thus, changing it would break the programmatic access.

  24. 68

    The bullets/asterisks/stars brings out the “ostrich” in humans. If I can’t see the password no one else can. And showing a password all at once is a very bad idea.

    I had written about this quite some time back providing a few suggestions. Do take a look. (It’s not some bogus link, I swear)

  25. 69

    Andrew Duthie

    October 28, 2012 6:51 pm

    I like the idea of using a checkbox to toggle password masking, so I threw together a jQuery plugin to demonstrate it in action. Perhaps some of you may find a use for it.

  26. 70

    You’re on cloud9? How could one use such an username?

    • 71

      That’s the wonders of the universe we call subliminal advertisement (or non-spot ads)… To bad, the ppl at Smashing didn’t catch this.

  27. 72

    Does no one uses IE10 or see how Windows 8 deal with password masking and revealing?

    I did a screencap:

    Maybe it’s an implementation method to consider.

  28. 73

    Mathias M. Stav

    October 29, 2012 5:36 am

    In my opinion this should be the users choice, i.e. a checkbox to turn on ‘show password’.

    • 74

      Mathias M. Stav

      October 29, 2012 5:42 am

      I tried to delete this comment, but all I got was ‘request failed’. The reson I want to delete it is cause I’ve changed my mind after using my brain a few minutes.

      • 75

        Haha. That happens to everyone!

        However, I don’t think an optional “show password” is a bad idea. I mention it in my overly long post further dow, but essentially what I said (I hope I don’t contradict myself), is that it works well on mobile because the user doesn’t have to go to much effort to select the “show password” check box, as they are already interacting with their touchscreen. It works less well on a desktop as the user has to move from. I keyboard to the mouse, and doesn’t fit into the process that smoothly.

        That said, it’s a harmless options to have underneath the password field as it doesn’t really take up much space.

  29. 76

    I’m really surprised that nobody has mentioned Jakob Nielson’s research ( which concluded that passwords should never be masked. He concluded that usability increased significantly, errors were reduced and also opined that password masking is totally unnecessary in today’s world. And I totally disagree with him. I’ve tried it myself and found it very discomforting to have a password box that is not masked. It gives me the same sort of shock as when I type my password accidentally into the unmasked user ID field. You can’t get rid of the masking. It would be like making handshakes illegal. Sure, you might slow the transmission of germs, but it doesn’t feel right in business situations. I think one of the the author’s original suggestions – to use a checkbox so the user can decide, on a case-by-case basis, is best. Still, I don’t like the extra clutter on the screen.

    • 77

      Let me put it this way:

      Masking exists for a reason. That reason is Security.

      From a User Experience point of view. If you improve a feature only to take away the reason the Feature exists in the first place, then you have failed.

      I can understand controlled unmasking.

      Automatic and/or Disabling Masking is a Risk in most if not all scenarios. This guy did not take into account Security, which is the reason why Masking exists, thus he failed to find a proper solution.

      The article here is proof that previous articles like that can convince unknowing people of something that simply isn’t true.

    • 78

      Nielson notoriously grabs the opposite end of the stick from common sense. Why? Because it creates controversy and shocks the senses. That, in turn, makes headlines, creates a buzz, and keeps him relevant.

      His conclusions are often tripe. But, being right is not the point. His controversy leads to attention for a field which is otherwise dry, esoteric, and flat out boring to most people. But when someone mentions the field of “usability,” guess whose name comes to mind — wrong or not.

      His antics, for better or worse, help make “usability” relevant, which (by the by) makes him relevant. But, it also led you to think about usability. So, totally disagree with him. At least you are thinking enough about the subject to draw the opposite conclusion.

      FWIW: Iin case it was not clear, I happen to agree with you, Alice.

  30. 79

    Interesting idea. In fact, Jakob Nielssen opted for losing the password masking quite a while ago already:

    As can be seen from the comments above, it’s still a controversial move. I’m neutral on the matter, and would emphasize on first taking a step back: Wherever and whenever you can, you should avoid creating your own authentication provider. It’s messy, hard to secure and much more complicated than one might think. Within company walls, use something like Active Directory or some other directory. On the public web, consider 3rd party authentication engines. Yes, I know they’re far from perfect. There may still be times when you need to create your own, but that should be an exception, not the rule.

  31. 80

    From a security perspective I think it is a totally no-go to show a password all at once.

  32. 81

    why could we not use unicode characters in password,while most sites now days are not allowing to use special characters, is too much technologies become a curse

    • 82

      If there is any actual legitimate reason, it would be in the back-end processing and storage not being able to deal with it. Same thing goes for maximum password length limitations. Usually this stuff goes into a database, so the field size, character set, and the desire to optimize the database for size as well as speed (big data storage problems) are all issues.

      The Unicode thing is a legacy problem. Nowadays, most tools can deal with it — especially UTF-8. Browsers are good with it. HTML pretty much demands it now. Global reach of the digital economy pretty much demands it now. Newer back-end technology (databases, programming languages, web servers, intermediate devices like load balancers, routers, proxies, caches, and so on) has caught up.

      I think the problem now is not a technological one, but one of habit, limited or outdated information, resistance to change, self-proclaimed gurus and their nonsense, and, of course, because why improve passwords when they have been proclaimed obsolete?

  33. 83

    Now this is going to upset a whole bunch of people.

    Just do away with the password!

    Read this….

    The more I think about this concept the more I agree with the idea. But spend some time with the idea, think it over and then come back with the issues on I really want to know why this is a bad idea, so far no one can give me a good enough reason why not. But I do worry the reason why not is so obvious I can’t see it.

    • 84

      Why down voting guys? It’s actually a proposal that Mozilla themselves came up with as well. No passwords is actually a viable solution.

      There is another problem with this however. And that is that in order to login, you always have to navigate back to somewhere else (ie. your email) and that’s very bad for UX. They might get distracted from more important emails, or who knows.

      Either way, it pulls them out of the immersion of your website, or they have to be really “eager” to join your site. As opposed to the “i know my password and I can login without having to go through my email first”.

      I have no problem with the idea, it’s a great idea to use Email for login. But it’s just not very user friendly, and there are not a lot of implementations that work very well out of the box. Not even Mozilla’s BrowserID or Mozilla Persona as it has been renamed.

      • 85

        This is the same thing in consequence — if not in the technical mechanics of its implementation — as having any third party even involved in the management of your identity, the proof of your identity, or the vouching for your trustworthiness.

        First, the scheme centers on some domain being authoritative, not you. Yet, Internet domains are *transient* in so many ways as to render them unreliable in the long term by their very nature. For one thing, they are not ultimately even within your control, even if you “own” them, as your “right” to a domain and your ability to use it are, in practical terms, purely at the pleasure of the registry, sponsoring registrar, host infrastructure, DNS provider, various levels of government, and (if they have their way) the UN. This requires a faith in a “web of trust” which contains entities whom, historically, cannot be trusted on their face. They certainly are not to be trusted by you over yourself.

        Secondly, no matter what this scheme pretends is the case, you can be tracked by the identity authority — albeit this scheme does protect effectively against tracking by the second party (a.k.a. the website with whom you are authenticating) as long as they are not in collusion with the third party (a.k.a. the identity authority). Even in the best case scenario that you “own” the entire domain acting as the identity authority, this is not ideal — given the above problem with the transient nature of domains. But, it gets worse.

        What if you “own” a mere email address on the domain? Then you don’t even have the (already tentative) privacy assurance of the scheme, which is only present if you “own” the domain acting as your identity authority. In the much more likely case that you don’t — and given that the scheme only requires ownership of a mere email account with the domain and not ownership of the whole domain — those that do “own” the domain *can* track you. Moreover, if there is a commercial gain to be realized, *who is to guarantee that they won’t*?

        Mozilla? They can’t do a thing about it… by design. They gave *you* the choice of the domain verifying your identity. As such, their scheme *locks you into your decision* because, now, if the domain later tracks you and you want to move to another to avoid that, you have the anchor of your email account keeping you there (assuming it has any value). Either you must sacrifice the account, create a whole new signing chain with a different domain as the identity authority, and have the whole mess potentially happen again — or you can live with it until you run your own domain and your own email service on that domain.

        Wow, that is so much more convenient than having a password only you know and keeping your identity in your hands for only you to manage, verify, and assert authority regarding.

        The scheme attempts to address the problem that not everyone has an exclusive presence online that a verification scheme can programmatically access. Under this scheme, a solution is attempted in two parts:

        1) Exclusive Presence: an email account is used as a proxy to address the first half of the problem, as everyone can be assumed to have and control one. But, the email account cannot be programmatically used for real-time response to the authentication query. Even for spam control, a service on the same domain is used to respond to such queries. Hence…
        2) Programmatic Verification: So, this scheme, likewise, uses a service on the same domain to address the second half of the problem. Unfortunately, the domain is not guaranteed to be exclusive to any one person. As such, this is where the technical limitation fails the logical requirement and creates a fallacy of logic to compensate — that the domain is trustworthy or in the interest of the user. This scheme then relies on this crutch and sweeps the shortcomings under the rug.

        Then, I’ve not even gotten into how nothing addresses the case of the domain lapsing, the verification service being down, the process of switching to a different identity authority from the perspective of the second party (the site with whom you are trying to authenticate), or which party is legally responsible for a compromise!

        Pop quiz. Who suffers the unforeseen (or, foreseen and, yet, ignored) complications? You guessed it. You.

        And all for what? So you can wrest control of your identity, delude yourself as to the privacy benefits, rely on a third party that may not be reliable, and *still* inconvenience yourself when the scheme blows up in your face?

        Why down voting guys?

        It’s not a good plan. That is why, guys.

  34. 86

    1) I’m curious how many mistakes people really make when filling out a masked 2 field form. I suspect it is not as horrible as many people suggest. A large portion of the population uses extremely simple passwords over and over again and probably don’t make many mistakes when typing their pet’s name or birthday for the 1000th time.
    2) Since those same people are so used to the current convention, many of them feel unsecure with unmasked password fields, even if they are alone. That’s a psychological effect you can’t do anything about.
    3) We as web/interaction designers are making a problem out of something that less tech savvy people don’t see as much as we do. I’d have no problem betting that everyone I know who doesn’t have a strong background in the web (because of their workfield, education, etc) would rather keep the double masked fields instead of the 2 proposed options, because it makes them feel safer.

  35. 87

    I agree; at no point should the password be revealed automatically, whether this is by default, or whether the confirmation password is different. An option to reveal password if required is useful on a touchscreen device because it’s quick to activate. However it is less useful on a desktop as the user will have to move from keyboard to mouse and as such will probably be used less. Nevertheless, it’s a good option to have.

    As a UXC at Foolproof, I don’t believe having a confirmation password field is a problem. I’ve never seen users in testing have an issue entering a confirmation password. On the contrary they are generally pleased that they have to, for the obvious reasons. Even slower typers are quite accommodating towards correcting errors as they acknowledge it was their mistake and is of importance to get right so they are not submitting an incorrect password, and are willing to spend the time to do this.

    I think it’s already been covered about temporarily unmasking the password as you type it as only useful for those that actually look at the screen as they type. On mobile this is slightly different as the keyboards highlight which key has been selected.

    There is a bigger issue here. Frustration is not through making typos when confirming the password, but when meeting password criteria that is not made clear from the outset, i.e. alphabetical, numerical, lower upper case, at least 7 digits, illegal symbols etc. The greatest frustration comes from having to re-type the password once you’ve completed it as it doesn’t meet the criteria (which isn’t made clear from the outset) and the user is only told once they have hit the submit button. This is the real issue.

    Over the years I’ve proposed very similar recommendations to solve this issue. But only the other day my colleague showed me a prototype he has been working on which clearly lists the criteria on the right of the entry fields and dynamically checks off each criteria as you meet it, whilst you’re typing your passwords. First and foremost, this is giving you positive reinforcement with green ticks, which is very important with regards to brand perception. Yes you still need to look at the screen with this solution, but there are two key differences, firstly; the criteria is there permanently and won’t vanish after half a second like temporarily unmasking a password. Secondly; you haven’t selected the submit button, which is actually a “I’ve completed it and ready for the next page” button. Once a user hits that submit button they have mentally moved on, and to stop them then with an error message is quite negative. Stop them before they mentally move on and you’re not increasing their frustration levels.

    So in summary. Users are very accepting towards entering a confirmation password, they are not accepting to not being informed of password criteria from the outset.

    • 88

      Now, see. I’d hire you. Your rationale is well thought out. Your process clearly provides for the needs of your users. You are willing to qualify your solution along with its limitations and shortcomings. And, you are willing to reconsider the problem criterion itself. Excellent post.

  36. 89

    Nexii Malthus

    November 5, 2012 1:28 am

    What about simple alternative of making the confirmation field optional?
    I don’t understand why it is setup as a requirement in the first place.
    JS can easily tell you if the confirmation field matches.

    If the user doesn’t type anything into the confirmation field just let it go, don’t make it a pain on the user.

    • 90

      Hi Nexii,

      I’m a huge believer in providing the user with options within which to make informed decisions, however in this case I firmly believe that the user should have to enter a password confirmation, the reason being it is for their own protection when they next sign into their new account. In fact I would say this is best practice at present.

      If you imagine a user that has incorrectly entered their password during sign up (without realising), they are going to be infuriated when they try and sign into their account for the first time. They will assume it is the fault of the site as they are obviously unaware that they entered a different password during sign up. I can imagine the comments now “but I use this password for everything, it’s not wrong!” This then creates a catastrophically bad impression of this brand which is very hard to undo.

      As I mentioned in my previous comment; entering a confirmation password is not an issue for users. I’ve never seen it as a problem in all the projects we have conducted here at Foolproof. The issue really is about making it clear what the criteria is up front so the user can adhere to it first time and not have to re-work their password in a guessing game!

      To your JS point; yes, it should absolutely be standard that if the confirmation password does not match the original, that the user is alerted to this before hitting the ‘Submit button’.

      • 91

        I completely agree.

        As a follow-up to the criteria for a password, let me just say that *this* is the nexus point of your password security.

        The security of a password is only as good as the password is at being an enigma. If you limit the characters that can be part of the password, or if you limit the maximum length of the password, you limit the strength of the password.

        A password’s strength is not a matter of including a mix of fancy characters. That is idiotic security theater at its most fruitless. Special characters, numbers, and spaces add nothing to the strength of the password. In fact, knowing that certain kinds of characters must appear a certain number of times in a password, and then also knowing that human psychology will dictate that most users will create a bare minimum adherence to your spec (more on this later), it has now become much easier to guess or otherwise crack a password.

        The password can be strengthened by increasing the minimum number of characters and increasing the size of the available set of characters which could comprise a password.

        Regarding the minimum number of characters, for each additional character required for a valid password, the number of possible character combinations that could be the password increases exponentially, as long as the minimum length of the password is smaller than the maximum length of the valid character set.

        Regarding the size of the character set, UTF-8, which all webpages comprised of living languages should now be using, is not only sufficiently large (thousands of possible characters), it includes characters that are not easily accessed on some keyboards (say, a US 105-key), but are easily accessible on others (say, a Japanese Kanji keyboard). This makes for extra layers of difficulty to compromise even dictionary-based single-word passwords.

        And, with regard to the adherence to your “password spec”, people’s needs are often in direct conflict with security needs, in that people need the password to be memorable or readily calculable from what information they can either remember or is in front of them. Therefore, in order that they can remember the password, people will often do the bare minimum to comply with the spec — and often, they only do that begrudgingly.

        If you require a minimum of 6 characters, unless the user’s “standard” password choice is longer, they will use exactly 6 characters. If you require at least one number, they will use exactly one number — often at the end of the password, and the number is usually “1”. This type of behavior defeats any entropy that may have resulted from complex requirements, often making each and every one of your user’s password *more* predictable. This is why requiring spaces, numbers, a mix of capital and lowercase letters, or special characters is pointless — but it makes for some great security theater.

        Since increasing the strength of a password is a function of having a larger number of characters in the password and having a sufficiently large set of possible characters from which the password can derive, a good password policy centers on these things. Everything else is trivial, provides less bang for the buck, and could even hurt security by adding complexity — and, therefore, provide more vectors of attack.

        So, what is the best password policy? From a strictly security perspective, have as large of a minimum number of characters as possible. But, that obviously conflicts with people’s needs and patience. So, have, instead, a moderately large minimum number of characters, and as large of a set of possible characters as can be. Allow, but do not require, special characters, numbers, spaces, etc. Require a certain minimum number of characters, knowing that most people will make their passwords exactly this long (because the longer it is the harder it is to remember). To increase the entropy deficiency arising from the psychological alignment to the minimum required size, you might consider using a “passphrase” instead of a “password” — meaning indicating to your users that they should create a memorable string containing multiple words with proper intrinsic punctuation, such as: “of course you realize, this mean war”

        Passphrases are great for entropy. They have variable length by virtue of a user’s natural propensity toward ending at the expression of a complete thought rather than focusing on an arbitrary character count. The choice of a dictionary word that meets the minimum character count is also mitigated by this, which addresses yet another attack vector. And, the best part of “passphrases” is that the implementation and mechanism for dealing with them is the same as a standard “password” scheme. You merely present the choice, and the users themselves implement this scenario for you — as a consequence of their own psychology — in their bare minimum attempt to meet the requirements of your spec. This *also serves their desire for convenience* because, while you will accept anything above the minimum character count (and thus, the user’s expectation of convenience will be satiated), the user’s desire to avoid the possibility of their chosen password being rejected (thus, inconveniencing them further) for non-adherence to your spec will drive them to do it for their own perceived benefit (the same mechanism they would normally use to defeat and render moot the imposition of complexity by the password spec). Effectively, this is reverse-psychology as a matter of practicality.

        I’d also like to point out that having users change their password periodically is another one of those pointless things oft touted yet left wanting. In security theater, periodic password changes are often coupled with complex password requirements. Yet, if the password scheme were actually secure in the least, changing the password periodically would not make it any more secure — since the original password, having thus far been strong enough to adequately resist being cracked, would be a *known* good password with *verifiable* security as evidenced through its *historical efficacy*. The usual argument that periodic password changes add another dimension of difficulty (temporal) against cracking attempts means nothing, as the only password being tested at any given moment is the *current* one — and the current password does not gain anything from the strength of its predecessors. If anything, the current password may be easier to crack than any one of its predecessors. The whole thing is a sock puppet, decidedly instituted to make the user feel like someone is actively watching out for their interest, when in fact that is not the case. It’s more often a grotesquely-conceived advertising excuse to keep one’s brand in the minds of its users while, at the same time, appearing to address legitimate concerns by “doing something.”

        Good job, Dan. Another great post!

  37. 92

    Apologies for the lack of spaces between paragraphs! Apparently you have to leave a double space before one is created. There’s a little UX issue for you right there.

    And this should be a new paragraph!!!

    • 93

      Damn. Seems I have no idea how to create a space between paragraphs! One would think hitting ‘enter’ would do it.

  38. 94

    This is a very interesting solution to solve the difficulties with the password field when signing up for a web service. As someone who is very interested in user experience and web development, I am immediately intrigued how simple the solution is, but I am not sure that it would be a good practice for most used websites such as Facebook, Twitter or Pinterest. I am often paranoid when I do sign up for forms, which is why when I sign up for websites that I use often or important forms, I do it at home, where I know there will not be many snoopers as opposed to a local Starbucks. This is where I favor the checkbox idea for temporarily unmasking the password, because it allows the user to control their security, if they signed up for Facebook in a local Starbucks. However, do you think the issue of password masking can be given to browser? Windows 8 already does this as many commenters mentioned: Just like what Amy and Dmitri said, what would you think if all browsers follow the same pattern of showing the last character typed, then timed? I believe it would resolve some of the security issues that your commenters have addressed here. Perhaps if all browsers follow this same pattern, then websites and web applications do not have to program solutions for unmasking passwords, and each website would have the same solution as offered by the browser. It may work, but there are users that might want to disable that all together, just like the user who asked the question to remove the eye symbol next to the password field.
    What I find difficult when creating passwords, as with many other commenters is password complexity. I often get frustrated that my password would require uppercase and lowercase letters, numbers and special characters which is probably how I tend to forget passwords in the first place. Sometimes I also forget that I have my caps lock button on during sign-up or when signing up for forms, and there I go – to the “forget my password” section. It is something I miss from Windows XP, as there would be a balloon stating that the caps lock button is set when typing my password. Perhaps if browsers reminded me that I have my caps lock button when I am typing my password whether I am signing up or logging in, it would be useful, but then again, there are people who would find that annoying. What would you think about having an indicator saying that the caps lock is on when creating or logging in with a password? Overall, I find this solution with temporarily unmasking passwords intriguing and something to think about. Perhaps like other commenters said, if we do A/B testing with this and see how users feel about this practice, then this unusual practice might be something that is common. Thank you for giving me an idea for easing sign-up forms in my next web application.

    • 95

      Good post, Harman.

      A Caps Lock indicator would be an excellent feedback mechanism that would help people who did not realize they had it on. It would not be a problem for people who intended it to be on, so long as there is no implication that having it on is somehow bad (like preventing input or a big red “X” or blinking text).

      In short, an indicator indicates. It should not judge. It should not interfere. It should not bounce around like it is on fire.

  39. 96

    Hello everybody. My solution looks like this. We have two fields, and that’s good. We typed in our password and now we need to confirm it. I would highlight bullets in confirmation field with green when symbol is right and with red when it’s wrong. To clarify everything i wrote, it would look like this. My password consists of 5 characters, and it is already typed in “Your Password” field, I’m starting to type it in “Confirm your password” field, I have already typed in 4 characters and the forth i wrong. In field it looks like this, first three characters is green and fourth is red. I think users will love this.

    • 97

      Pavlo, I think color-blind users will hate this. Various degrees of color-blindness exist in a significant percentage of people all over the world. You could use this, but you would do well to add an element that does not depend upon the ability to distinguish hues. Also, this does not help those who rely upon screen-readers to announce your feedback to them because they are only partially sighted or even fully blind. For that, you would need to actually modify the DOM, not just change the visual styling (which would be ignored by non-visual media).

  40. 98

    I have several points in perspective.

    Not that I have diverging opinions- I mean I’m a systems architect, developer, business owner, and user depending on which site and system is being spoken of.

    I also think it’s important to be somewhat consistent about the expectations offered in each of these roles, because otherwise users and developers may not see eye to eye- ever. I might argue for different things based on what my specific role is.

    My bank does not let me include special characters in the password. As an average user I might not care. As an avid tech fan, I think that’s lame. As a developer I think “How effen cheap!” I would much rather be able to include special chars for security.

    Because I want a more secure experience. I would not ever set my banking password in public, so actually I don’t care whether they mask it when I set it. But we’re not talking about banks, are we.

    Recently I just implemented the “password change” box to solve the situation where my client wanted a completely masked password, but didn’t want to add a second box to confirm password. We discussed implementing with jQuery a situation similar to phones, where the password pops the letter entered for a second before becoming masked.

    Let’s look at the context: the signup form is in the flow of a user signing up for free membership, and in lieu of registering with FB through OAuth, they can create an account providing email, username and password. That’s already 2 more fields than I recommended for this exercise… adding a 4th is ludicrous. Given that someone will get 1 shot to set a correct password as they intended or else it will mean tech and customer service and ?? to square them away, and because this will be perceived as a non-critical site (one that depends somewhat on the ease of usability and the signup process being painless) it makes sense to offer the mask/unmask approach, at least the client and agree agree as such.

    But I’m not going to try to build a case for this solution to be used ALL the time, nor any other.

    Intent comes into play in UX and soundness of design is relative to the function being sought after. Sometimes it’s a business function, sometimes it’s a usability function, sometimes decisions really are just a function of budget, but in a pure sense it all boils down to there isn’t a one-size-fits-all solution. It’s good to have choices, be able to implement choices, and to be mindful of the actual needs in a given situation and play toward those. I believe that’s all any of us really have.

  41. 99

    Ahsan Idrisi

    June 26, 2014 4:40 pm

    I have a new pattern suggestion for Password field and it will solve the solution of the current SHOW PASSWORD security problem , anybody near me can see my password

    Please see this UX pattern for password field in action here


↑ Back to top