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.

EDIT:

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

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

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.

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.

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.

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.

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

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.

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.

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.

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

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?

No one has mentioned Lotus Notes solution to this problem. They fired a function that would change the image on the login page with every keyboard hit. Something like this could provide some feedback to users, while still retaining a hidden password.

Jeff's article ^[1] on the matter however doesn't paint the feature in positive light.

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

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.

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.

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.

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 :)

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.

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 ^[1]) - 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..

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 :)

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.

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.

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 :)

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

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.

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?

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

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.

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.

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.

https://welcome23.smile.co.uk/SmileWeb/start.do

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

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(!)...in 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 ^[1] 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 ^[2] or this ^[3]), 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.

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!).

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

2.

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

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.