From Jacob Nielson's "Stop Password Masking":

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn't even increase security, but it does cost you business due to login failures.

What do you guys think?

+148  A: 

Totally disagree. Often we're doing presentations where multiple developers need to log on to multiple machines, and this has to be done in full view of many audience members.


"It does cost you business in terms of login failures"

This is far-fetched in my opinion. In a workplace, you often have people looking over your shoulder at your screen. The "cost", if there even is one, is completely offset by the number of practical jokes and industrial espionage episodes you avoid by not letting people watch others log in. Even using an optional checkbox to mask the password is simply adding a dangerous feature, rather than any real business gain.

Also... funny story about password masking - one of our guys had his password set to a swear word followed by the name of his manager. He of course started logging in before the focus was set... pressed tab, and the cursor moved to the first box, and began typing in his password... he's not here anymore.

Edit 2: regarding a checkbox, since many people feel that's a good compromise - the above anecdote would occur much more frequently, as people will then be forced to remember to check the checkbox to hide their password if they usually default it to off. I really think it's a dangerous feature that adds almost no value, and question the idea that masking carries any sort of business cost at all.

Very good point!
Gab Royer
it's bad enough that a simple install of wireshark can sniff most logins.
Matthew Whited
I always feel a little jolt when I start typing my password and see it unobscured. It just feels wrong.
Andrew Keeton
...someone tell ol' Jake that they invented the "forgot password" link a while back. I'd be willing to be that any user having problems typing in their passwords or logging in is going to click that link and either reset their password immediately and log in or copy and paste it from the email that results and log in (depending on implementation).
I doubt a clear text password box for any business application would ever pass Sarbanes-Oxley (or the Canadian versions like Bill 198). All the fuss to ensure that every person, no matter how low level, uses a unique login wouldn't mesh well with "accounting passwords are free to anyone walking by that cubicle"
the amount of times at work in meetings people have to logon with the screen being projected to a room full of people...
+1 just to pass from the "69" :)
Think of WPA passwords, and Windows XP handling of it and Linux's NetworkMAnager handling of it. On Windows the password (consisting in my case +40 chars) is always obscured, while on NetworkManager there is a nifty checkbox asking me if I wan't to see the typed password. If the computer is never left alone to other people (There is fast logout everybody), this shouldn't be a security issue, and a big improvement to usability. Furthermore, we could start issuing hardware keys, sidestepping the whole "masking passwords" issue.
I think we should skip hardware keys and go straight to bio-chips :D
I always love it when I watch someone using a proector login and don't press enter/tab properly and press # instead: username#password.
Callum Rogers
Your anecdote isn't very compelling. If employees follow wise business etiquette, then this is not an issue. Just as you don't use anything remotely offensive (per your audience) in code, comments, test data, etc, you should think about everything you do at work. In the eyes of most employers, you don't own your work station, your account, your password, or anything that you type or do while they're paying you. So if your ex-coworker wanted to keep his job, s/he should have acted accordingly.
Justin Johnson
People tend to use that dirty little secret as their password, you are certainly never going to forget it. Making it all visible just gives rise to obvious passwords since you now have to be cautious of the password you select, lest the guys next do peeps over you shoulder.
+21  A: 

Personally, I like the approach implemented in Opera Mobile - password boxes display each character for a second or two before it reverts to an asterisk.

David M
Now that's a cool idea.
Jonathan Sampson
I also really like this on a mobile device, but I worry that on a projected screen it wouldn't help anyone paying attention!
I agree with overslacked... this idea is fine (for the most part) on mobile devices, but should be avoided on it's big, desktop, brother.
Matthew Whited
SonyEricsson does this as well.
Apple do this on the iphone too and it really makes a difference on the touch screen keyboard. I'm not sure that I'd like to see it applied to other cases unless there was a double verification, eg password and security question, to make it more difficult for people to capture all the login info in a quick look. Even at that i'm not sure. The benefit of mobile devices if you can hold it close to you and obscure it.
It's also more important on the iPhone. I'm typing this on an actual keyboard, so I know what characters are coming out. The iPhone keyboard is not nearly as predictable, and so I need to see the characters coming out of it. (Then there was the time I couldn't log in until I got my keyboard replaced - unpredictable keybounce with letters in my password.)
David Thornley
+54  A: 

I like the checkbox option of masking passwords--on by default.

Me too, but it forces one more piece of thought/information into your users' heads.
Better than struggling with entering the password multiple times, and it's a good security/usability compromise.
Maybe instead of a check box, have some type of key-combo that enables/disables it.
Yes, a checkbox or "unmask" button would be a great solution for people who know that their password won't be seen. For the technically-inclined, there is a bookmarklet floating around that will display a alert of all text in password fields. Useful if your pw was saved but you forgot what it was!
It would be a little expander called "Show what I typed" - having done that, there'd be one saying "Hide what I typed."
Drew Hoskins
The only way this MIGHT be OK is if the user was compelled to click and hold a small button to show the password. When the user released the mouse button, the password would immediately be obscured again. But I still think that's too much risk.
Robert Harvey
@robert: I think you're overthinking it. Look at NetworkManager's way of doing it and tell me if that is really a security risk. Of course, on a login screen, the checkbox should be on a position that is harder to check by accident, maybe hidden by a button or something.
"MIGHT be OK"? The checkbox is on by default (meaning passwords are masked). If you want to see the password, you turn it off. Next time you get to that login...the checkbox is *still* on by default. You have to check it every time. This way you're always presented with the more secure option first. Not a hard concept.
The checkbox should be disabled when the box is not empty and its contents are masked. That would make it impossible to click the box and reveal a masked password -- either accidentally or maliciously.
Patrick McElhaney
Off by default I can agree. On by default greatly reduces the usability IMO. People who have problems with their passwords are likely the same sort of people who would be confused with the checkbox. It really depends on the context though. If it's an app or system you regularly use in public the rules will be different than the rules for the computer in your bedroom.
Bryan Oakley
@Patrick: You want to prevent that someone enters his password, then runs out of the office before clicking OK?
@Bryan: Depends on the number of visitors to your bedroom ;)
Yeah, best of both worlds!
Andrei Rinea

I think the idea is ridiculous. Why do I need to hide my password from myself? If I'm afraid of someone peeking over my shoulder, (such as at a internet cafe) I should be allowed the option to mask it. But it shouldn't be masked by default.

This practice should be stopped IMO. I refuse to login to some sites just for this reason.

You "refuse to login to some site just for this reason"? Really? Seriously, now.
Jonathan Sampson
you must not log into many places
Matthew Whited
How do you log into any sites? I've never seen a single site that doesn't mask their password entry
Making a input type password will auto do the bullets/asterisk based on the web browser. You could easily circumvent that behaviour on a ua level, rather than the site having to do it.
Rich Bradshaw
I think he imagines that he can see his password. This lets him sign in.
Maybe he just uses periods or stars and just thinks the bullets are his password.
Matthew Whited
The interesting thing is he said that...while signed in to SO :)
Jonathan Sampson
Password bullets have plenty of opportunities to bully me, but only because I use 9-12 char strong passwords with variable case :) It may take two or three attempts to login if I'm typing fast!
Jonathan Sampson
+1 for sheer ridiculousness, with a side of obtuseness. :D
@Jonathan Sampson: While the statement about refusing to sign in is indeed ridiculous, SO is using OpenID (and nothing mandates the OpenID producer uses password-based auth), so I don't see anything wrong with this.
+1 for your position. This isn't Slashdot.
Robert S.
Based on his name, maybe he's just playing devil's advocate?
@Jonathan Simpleton: Adding to the above comment... I also said I refuse to sign into "some" sites. Maybe you ought to look up the definition of the word "some".
+36  A: 

I'm very surprised he doesn't mention anything about password masking lending a feeling (however incorrect) of security to a site. Just as we're apt to think food in a better package tastes better, most people will believe a password mask makes an application more secure.

I think that for practical reasons it's a good idea, but that it'd be a serious cognitive issue for a lot of users.

precisely why I think not masking passwords would actually worsen user experience
Abi Noda
Here here! Most people who use the Internet know how to use a masked password box. They're used to it. The cost of perceived insecurity is easily enough to offset any added support costs incurred.
Ach it's "hear hear!". That drives me crazy!
Mike Robinson
@Mike Robinson: your being to picky. May be there righting it write!
@Beska <cringe>..well played sir
Mike Robinson
Ouch ouch ouch! It hurtses, Beska!
+8  A: 

I think masking is definetly worth the security. How many times have you logged into something with somebody or a whole group of people watching you? Yeah... lets just give everyone very very easy access to our stuff.

Justin Balvanz
I hate when I write quick test code and I need to login (such as an authenticated web request). I have found myself checking my password into source control on more than one occasion. I have changed to even prompting for passwords in my spike code console apps.
Matthew Whited
The "whole group watching" you can then, very well, read your keystrokes on the keycaps.
Andrei Rinea
+2  A: 

I think the average user would be surprised to see their password being shown when logging in so disagree that it should always be clear.

I do agree with the part of the article that suggests to at least have a checkbox asking the user if they would like to mask their password.

An advantage of having a masked password is that usually the Copy command doesn't work on it - preventing you from doing a copy/paste to see what is there.

+3  A: 

I disagree as well. It's one thing to make a point out of not letting usability suffer by design, but security should always be the number 1 priority

As long as the security goals are balanced. If you make something too secure it isn't usable. You want to have a good balance of usability, security, and other characteristics of quality.
+4  A: 

It's convention; users will not expect to see their password as they type it, so most devs (me inc) will always mask it.

+6  A: 

Being able to see your password while typing it could stop a few 'fat finger' mistakes, but overall it would make the application already seem insecure to a common user before they even log in.

I know if I was on a webpage logging in and the input box was not of the password type, and didn't mask my password, I would be pretty weary what information I gave that site.

Austyn Mahoney

The only feedback is the row of bullets? Does the submitter not know how to touch type? If not, then that is the problem, not the masked passwords.

better still... do they not have memory. Even hunt and peck works well with obsurced password. What about the fun tricks of showing different numbers of stars or not showing anything as someone types their password
Matthew Whited
+4  A: 

Wouldn't a password manager resolve the issue of failed logins? I know developers can't assume that users will even have a password manager, much less use it, but maybe we need to do a better job of promoting their use. Security is always paramount, but a decent password manager can go a long way towards helping users practice more secure behavior (such as avoiding using the same password for every site, say) as well as increase the usability of sites that require secure logins.

Along those lines, what password manager do SO members use? I myself use 1Password, and I like it a lot, especially as it integrates into both Safari and Firefox (and others, but those are the browsers I use), and it syncs across all my computers via Dropbox. Other recommendations?

Alex Basson
I just use the Keychain on Mac OS X. Any half-decent OS X app utilizes the Keychain.
+17  A: 

I think Nielson has got this one completely wrong this time.

People are used to the bullets because, as another poster pointed out, it lends a sense of security and confidence in the site/application.

It's up there with "I like to leave my front door open just in case I lose my keys when I'm out".

+2  A: 

Its an interesting idea, one that has been touched a bit by mobile applications as people have already said, but I think the 'usage in public' factor along with the perceived security makes it more useful than harmful. You can hash and obscure passwords all you want on your backend and db, but all it takes is one window left open with 'rosy182' and all that security work is wasted. Im sure more money has been stolen from lost wallets than from bank heists over the years :)

Wesley D. Radcliffe
+9  A: 

A hybrid solution may be what some smartphone software (iPhone and Android OS, among others) does. It shows you the last typed character, and converts it to a bullet when the next character is entered.

The plaintext character appears about 5 seconds. It eventually timesout, and converts to a bullet.

This feature has saved me from myself a few times.

alt text

if you had a tactile keyboard this wouldn't be as necessary :)
Matthew Whited
It's not limited to the iPhone; Opera Mobile and Opera Mini do it, too.
again, this feature is good if nobody's viewing. If standing in front of an audience, 5 secs per character would be enough for everybody to write down your full password..
Android also does it.. so no it's not some revolutionary feature only included on the iPhone. I'm sure there is more "prior art" on it too, but as Andy pointed out, not good if anyone is ever viewing your screen.
Austyn Mahoney
I find this feature a bit confusing, it makes me start thinking and attempting to remember where I'm at in the typing process instead of just punching the password in - as fast as I can.
@thomask: why the downvote though?
Because I find the feature confusing
+2  A: 

I think it all depends on the situation. I think it would be good if most sites and programs gave you the option to display your password unmasked but not necessary as most of the time users don't use rididculously long easy to misspell passwords, but some things like network keys can be ridiculously long and I love the fact that Vista gives me the option to display my network key as I am typing it in because otherwise I would probably misspell it nine times out of ten when connecting new computers to my wireless network.

Andrew Marsh
you could always type it in a text file using something like notepad and then copy and paste those long passwords (I keep my WiFi keys on a secure USB drive just for this)
Matthew Whited
+17  A: 

Rather than having each website give you an option (or not) to mask your password, wouldn't it be better if the web browser gave you the choice, browser-wide? Or possibly even the operating system? Seems like site-control of this feature would be undesirable, since users' needs can be wildly different.

Chris Mazzola
bingo! There are a million and one ways a browser or operating system could implement compromises on this. And, in good OO form, remember that when a web designer says <input type="password">, she's specifying function, not implementation.
David Berger
I'm seeing a lot of the answers thinking only in websites. On websites it would be a bad idea, but what about other password fields we encounter?
+100 isn't enough
+1  A: 

I like the checkbox, a la Apple's Airport WAP/WEP key field. I often need to give the password to my own network out to guests, and would have forgotten it 100 times over if not for the ability to make it visible.

What about the system-level checks that seem to be in place for password fields, such as blocking Copy (Ctrl+C) operations? I don't know that there's one way that's right for every application, but I don't like the "hurr users don't know what's best for them" vibe this thread is getting. If the user wants to see their password, they should be able to see it. Better than writing it down and sticking it to their monitor :)

Chris McCall

One option that could work in some cases but not all (just a far out thought from the world of crypto) would be to have a key in a file generated for the user, rather than type a password the file could be submitted. It wouldn't be a practical solution for many cases but perhaps with a bit of thought and some clever interface design it could be made to work for cases that need a truly secure password that can be much easier submitted (in comparison to a password of this level being remembered). The main problem being if used on the web you would limit your login locations unless the file was carried on a flash drive. I'm not sure if/how it could be practically implemented but if security and ease of entering passwords are the key goals then it could maybe be adapted, it is truly an incomplete thought though (just hoping it generates ideas more than anything else).

+1  A: 

Sometimes someone is sitting next to you and he might see your password ...

what i think is use a checkbox to mask/unmask password if the user wants to see what he typed he can just uncheck it :)

+1  A: 

If a site doesn't mask a password, I get real worried.

My anxiety is not that I think someone is going to peek over my shoulder. My anxiety is based on the fact that the creators of the site either do not know input type=password or didn't follow the convention. And if they are either than ignorant or against the grain, then they have probably done worse things, like not encrypting it when it's sent across the wire.

Of course, having it masked by default with an option to turn the masking off is acceptable, if not ideal.

Aaron Daniels
+1  A: 

How about a checkbox marked 'Protect password' or 'Hide password'

After a failed login, in goes back to masking passwords and it times out after about 30 seconds so nobody could unmask passwords.

Even better maybe would be a large grid of random symbols that change whenever you type a letter. People would remember what symbols each changes to so they know if the password is correct so far. This is what SAP did.

+3  A: 
Gavin Miller
You're using Lotus Notes as an authoritative source for a user interface practice? Eeek...
Robert Harvey
@Robert Harvey, Lotus Notes has a high Eeek factor ;-).
+26  A: 

99% of applications and websites use masking as the defacto approach to protecting an individual's privacy and identity. Making passwords visible as cleartext is a recipe for trouble. In this day and age of identity theft and anonymous internet fraud I am surprised that anyone would be advocating for cleartext passwords.

Even if your site does not manage confidential or secure information, there are several strong reasons for masking passwords as a practice:

  • Even though they shouldn't, many users often use the same password for multiple sites. Since user names are generally NOT masked, this makes it easy for an attacker to scan through common sites (such as banking and credit card sites) and attempt to log-in with the same password.
  • As users become more savvy about internet security, they are likely to perceive any site that doesn't mask passwords as one that may potentially have other security flaws as well. This is more likely to lose you business than any number of failed fat-fingered log in attempts. It also acts as a welcome mat for anyone looking for a site to attack.
  • Masked password fields are also protected from copy/paste operations by most operating systems and browsers. This adds an enhanced level of security against both manual attacks (attempting to Ctrl+C someone's password) as well as automated attacks (e.g. cross-site script injection).

In my opinion, masking should probably be extended to the user ID field in certain scenarios as well. For instance, a website I use chose to make my social security number the user ID - and there's no way to change it. Now, this is a bad practice, to be sure ... but if the user ID field was at least masked it would be less of a risk.

Ultimately, you shouldn't worry about the small number of customers who may be unhappy with failed login attempts. What you should worry about is the damage to the reputation of your company from security breaches. Any user who actually is willing to use your service won't care about the masked password entry.

Totally agree with all of your points...surprised that the question was even asked. Even more surprised that there is an apparently authoritative source that advocates this view.
Robert Harvey
Even more surprised that there are alternate "solutions" being posited...or that the user should somehow control this.
Robert Harvey
You made some fantastic points! I hadn't thought about #3.
I agree with your points, but I question whether you have data to back up your '99%' claim.
@Superstringcheese - The 99% figure was [hyperbole]( The phrase *"99%"* is typically used as a figure of speech to mean *"nearly all"*. If I had said that 87.3% of websites use masking then you'd have some merit in asking me where my data comes from. My intent was just to make the point that the vast majority of websites and applications use password masking as a means to provide security and confidentiality of a user's credentials. I don't have any specific research to state exactly what that percentage is.
@LBushkin - I have merit in asking where your data comes from because you assert that a majority (50%+) of (presumably the total set of all) sites and apps share some feature. My point, regardless of the actual number you quoted, is that one should qualify such statements as being based on either anecdotal or empirical evidence.
@Superstringcheese: I largely agree with that point, and I'll reiterate that I don't have specific research to back that assertion. It's entirely anecdotal.
+1  A: 

Not using <input type="password"> will break password managers which recognize login forms by presence of this field.

+2  A: 

Making the password is fine for the most part - but there are times I want my password to be visible (so I don't mistype long/complex passwords)

Showing the password in plain-text (with no toggle) is a bad idea - there are times you want to obscure it (as others have mentioned, when other people are watching your screen - presentations, screencasts, random near-by people)..

Having a checkbox to "show password" seems like the obvious solution, but this can be a security problem with auto-complete - someone can load up the application (or the webpage in a browser), click the button and trivially see your password (which you reuse for everything)

The iPhone has an interesting password input system (see pcampbell's answer) - it shows one letter at a time, as you enter them (timing out after a few seconds)

This method allows users to see what they enter (giving the user more useful feedback than a bunch of *s), and it solves the "evil user seeing your auto-saved password" problem - since they'd just see the usual ******** (because it wasn't entered in the last 5 seconds)

Of course you still need a checkbox to toggle this (since if someone sees each letter of your password it may as well display the whole thing!), but it seems like the best compromise between plain-text and masking..


No part of the password should ever be displayed if there is a possibility that it can be seen in public, which is always. That wipes out half of the posts here.

The user should not, cannot, and must not control this. Which wipes out the other half of the posts here.

Robert Harvey

Note, as a point of interest, Smile Internet banking in the UK kinda does this, for about a year now.

Type in any 16 digit number as a credit card and note how it then asks you for your pin as a drop down box? Granted, it changes to a * after selection, but still, I would never log in to my smile bank account with people watching.

Also note the next and final security stage does use a traditional password box.


I think there would be a lot of confusion if there was a masked option as tickbox - as many would forget to unmask/untick it.

And imagine when you save your password. WIthout it being masked, people will see your password when they use your computer - its more insecure.


Jakob is just yapping because he can. Take a look at his site, is it really any more "usable" then yahoo, google, bing, ect? eh.. no.

Jakob's site is harder if you ask me. To him it may be super accessible. To me his links on the right side are hard as hell to read. I don't even know what is going on with the left side. It looks like a bunch of crap some new html designer become programmer made (talking about the homepage here). Lets see... let me through some css on every tag on my page, that sounds usable. Then we will show every one my password.. genius.

If my password was not masked, I personally would leave the site right then and there. Never come back. Gone. "What type of gone are we talking about here?.." the type of gone as in I seem to have forgot that this site even existed gone.

There would be nothing better to me then typing in my password in front of a co-worker/friend/family member without it being hidden, just to come back to my computer with god only knows what kind of pranks played on my computer. If they have not just changed the login on the site all together.

1 more thing. Just imagine reading that site with a screen reader.. lol. See how nice those tables act, blah, fail. There are many reasons people avoid tables, one being usablilty for screen readers.

Comic writers have fun, perfect material. I can see it in my head now....

Ellen B

I think Password Masking versus Plain text both have merits BUT this will all depend on context.

In the context of mobile pages / apps being browsed on a mobile phone - password masking could be dropped. Whose looking over your shoulder and going to see your password? No one really - a mobile phone is a "single player" device.

In the context of desktop apps/web apps/atms(!) fact almost every other context where login functionality is provided on a display this is not a "babyface" like on mobile phones, password masking is required IMO.

Reasons being:

  1. These displays are large enough to not be "single player" displays
  2. Password masking is a standard - dropping it breaks users familiarity and general consistency with using login functionality. Users require consistency to re-inforce their familiarity with login functionality they would have used elsewhere. Plain text passwords will break this consistency and make users seriously question the overall security of the application as familiarity is broken and user expectations become uncertain.

I'm sure with more extensive review of this proposal a better recommendation for th euse of plain text versus masked passwords can be established that is CONTEXT based.

I think Nielsen left the context-based factor out - it make his proposal more sensational.

Good question - I think usability issues should be discussed within a dev forum. Its critical


When I originally read this article on slashdot I was blown away by how completely naive a supposed UI expert could sound. I mean, I would be intrigued if he was introducing some new way of password masking that helped prevent the user from blundering when entering his or her own password out while at the same time not comprising security (perhaps something like the this or this), but his thesis of simply dropping masking all together is pretty ridiculous.


Simple answer: Yes, please! If my coworker is standing right beside me and looking over my shoulder, i don't want him to see my password in clear-text on the screen.


I'm seeing a lot of the answers thinking only in websites. On websites it would be a bad idea, but what about other password fields we encounter?

Think of WPA passwords, and Windows XP handling of it and Linux's NetworkMAnager handling of it. On Windows the password (consisting in my case +40 chars) is always obscured, while on NetworkManager there is a nifty checkbox asking me if I wan't to see the typed password. If the computer is never left alone to other people (There is "lock screen" everybody), this shouldn't be a security issue, and a big improvement to usability.

Furthermore, we could start issuing hardware keys, sidestepping the whole "masking passwords" issue.

Of course, on a login screen, the checkbox should be on a position that is harder to check by accident, maybe hidden by a button or something.


Browser and software maker should give users a choice. A checkbox next to every password field to unmask the password. Problem solved and Jacob Nielson can go an yap about other "problems".

I work as software developer in a large company and on every day numerous users forget their passwords and lose HOURS AND HOURS of productivity because the helpdesk has to verify with their superiors whether to reset the passwords - due to a stupid restriction that when you incorrectly enter your password 3 times you're locked out of the system.

That brings me to the next thing... 3 times and you're locket out is bad software design. Better use a time delay that doubles each time which is also an effective weapon against brute force attacks. First delay 2 secs, 4 secs, 8 secs etc...


There are size approaches to password masking:

  1. Traditional masking (type="password")
  2. No masking at all (type="text")
  3. Optional masking, turned on by default (type="password/text")
  4. Optional masking, turned off by default (type="text/password")
  5. Delayed masking ala iPhone, Andriod phones, etc (type="doityourselfzomgmagicbbq")
  6. No-response/blank masking ala bash and other terminals

We can't really argue with approach 1. It's the standard to which millions of users have grown accustomed. Why break what really isn't broken. Approach 2 is, imho, just plain silly: no one will trust your application.

In my opinion, Approach 3, is the best of both worlds. "Normal" users will probably never know it's there since it appears as a normal password field by default; yet, it gives more sophisticated users the control to switch back and forth between masked and unmasked. This is typically found in applications that require extremely long passwords (like 32+ character WPA keys).

Approach 4 is probably more suitable for low-risk and trivial applications, but I wouldn't use it.

Approach 5 is a neat idea, but difficult to implement well (still behaves like a normal input field, etc) in HTML. It's great for mobile devices and platforms that support it as a native control, but for general use in web applications, it might be more trouble than its worth.

Approach 6 is the norm for command line applications (you type your password but nothing appears on screen). This may be considered as even more secure (since password length cannot be seen), but since users are accustomed to having some sort of response for almost every action they make in a web application, this approach probably wouldn't be accepted well, resulting in much confusion and frustration.

Justin Johnson

Let's simplify and say the problem we want to solve is human error preventing large passwords due to input errors. We can do this without revealing the password to shoulder surfers, but we will have to sacrifice a bit of entropy.

For example, for each character entered, we could store the last bit of the SHA1 hash of the password so far. If the check bit of the text being entered differs from the stored check bit, notify the user.

Now errors get detected soon after they are made, the user backs up a few characters, and continues. We lose 1 bit of entropy per character, so the password would have to be longer (hey, we were doing this for long passwords in the first place!).

making it easy for hackers, are we?
Right, you lose 1 bit of entropy per character. I said that.
Maybe I misunderstood what you're saying, but it sounds to me that you'd like the user to be notified each time he/she inputs a wrong character. That's absolutely not secure as you'd be reducing an n-char long password to n 1-char long passwords which would then be supereasy to crack.
No, it only has a slightly-more-than-50% chance of detecting a wrong character. If you make the error near the start, each new character is another 50% chance to be notified.
@Strilanc: I don't get it... Say I enter "a" and the software tells me "Error". So I delete it, enter "b" and so on... until I find the good char. In the average case this would take me, say, 10-15 tries. Now, on to the second char. I already know the first so that's fixed, I repeat the process and in other 10-15 tries I have the 2nd one. And so on. For a 10 char password I just need say 3-400 tries, instead of the billions of combinations needed to normally brute-force a 10-char password.
Only half of the bad characters will produce a warning when you make the error. Then, on the next character, half of all the characters will produce a warning. Same for the next and the next. The server only has 1 bit of the hash at each step.There is a 2^8 chance you will enter 8 bad characters, but ~100^8 passwords of that length. Thus the number of 8-char possibilities the server doesn't warn about is 100^8/2^8 = 50^8.

There's a chapter by Tog (Bruce Tognazzini) which goes into quite a bit of detail about password masking. It's in the book "Security and Usability", edited by Cranor and Garfinkel. Anyway, IIRC they concluded that delayed coverage of the password characters by 'dots' only reduced password entry errors if there were three or more characters still visible, but then it didn't help to reduce the success of eavesdropping. If combined with displaying the visible characters in low contrast - I think they used the example of light grey on white - and if the first few characters are always hidden, then it's both easier to enter and harder to shoulder-surf.

Graham Lee
+1  A: 

One thing nobody has noted yet: all the major email sites/programs, OS's, networking sites, etc., use password inputs with the characters obscured. A big part of usability is simply fulfilling user expectations. Since everything is setting the expectation that passwords will be obscured, unobscured passwords aren't more user-friendly.

+2  A: 

I think you should be able to turn masking off if you want to.

Most of the time, I'm browsing the internet at home. Who's behind me? Well possibly the dog, but he's pretty trustworthy.

I can usually type my passwords blind, but some of them are pretty long. As an example, my wifi key used to be over 40 characters long. I had to change it in the end though because the systems I used were mostly 'masked' only and it was so easy to make a mistake that it took many attempts to get it right. So, because I wasn't offered "Show Passwords", my wifi security has been reduced for the sake of my sanity.

As people do log in from public areas, and because there is an expectation that passwords == lots of stars, I agree you should mask them by default. But I see no reason why it would hurt to give them a checkbox that turned the masking off.


Even with the option to unmask, here's the unfortunate conversation that happens to those of us that are security minded:

  • Me: [logging on with mask option selected]
  • Friend: why do you have that as all dots? You can turn it off right there so you can see what you're typing.
  • Me: then you would see what I'm typing.
  • Friend: and?
  • Me: not you. I mean anyone.
  • Friend: but it's just me here. I take it you don't trust me.
  • Me: it's not that, I just don't change it to plaintext ever. On principle. Just in case.
  • Friend: in case what? It's just me. [awkward silence]

Now why was it that any of this conversation needed to take place even once? Much less repeatedly?

just type the password really fast, your friend won't have time to complain about he not knowing your password (which he should not, even if he's your best friend ever)

Passwords are awesome! But sometimes they are annoying...

  1. its necessary if another person is viewing the screen (beside you or remotely...) so going plain is no option. you could provide an alternative, but thats probably not worth the effort or the extra button


apps/browsers etc KNOW HOW TO DEAL with passwords, and the user can configure it to his needs. he/she is asked whether the password should be saved etc. by default all text input data is saved and you can double click it and see the previous submits. imagine that for passwords? god no! also you cant save the password if you want to...

so yeah. we definately should mask passwords

Joe Hopfgartner
comment? ...............
Joe Hopfgartner