Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. 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. 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.

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.


SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ 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?


↑ Back to top