Passwords are sent as plaintext in HTTP, even if it's an input with type set to password.

I like the idea very much, as I've often thought the same.
Here's a Link for the lazy folks [useit.com]

Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they're using an Internet cafe. It's therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there's a tension between security and usability, sometimes security should win.

that's actually a great way to do it, and a few apps do it like that (truecrypt comes to mind), allthough they reverse it (password is masked but a "show password"-checkbox exists).

It's therefore worth offering them a checkbox to have their passwords masked

Odd to be talking about password usability and then add in MORE confusion for the user with unnecessary checkboxes they've likely never encountered before.

I'm pretty sure my mother would prefer a checkbox, esp. when its description is non-technical (e.g. "check here if you're in a public place like an internet cafe") and be able to see her password. She's not that into computers and makes alot of typos .. she told me herself that she uses simple and short passwords so she doesn't have to retry all the time because of typos. That's exactly what Nielsen is talking about and it's definetly not what you want your users to do.

Would have saved me some trouble the other day when I reset a password without noticing that the caps lock was on.

With all the people used to having their passwords masked when they type, most likely not masking them would lead to numerous phone calls/e-mail messages of outrage from users because their passwords aren't hidden any more.

And yes, many of those people are probably the same ones who enter credit card information without verifying that the information will be sent to a secure server. :(

On the other hand, we don't mask credit card numbers when they are entered. So I guess it sounds like kind of a double standard...

that's actually a great way to do it, and a few apps do it like that (truecrypt comes to mind), allthough they reverse it (password is masked but a "show password"-checkbox exists).

I'm in favor of this approach. Most of the time the box would remain unchecked and the password masked as usual. But there are some times when you really need to see the password because it keeps getting rejected. The caps lock issue raised by piatkow is a good example.

I have used the checkbox a couple times. But, more often, I have checked for whether Caps Lock is on or not.

Both approaches require JavaScript to work.

My suggestion:

- Use <input type="password">
- Supply checkbox (or button/image) to toggle the type of the password field to type="text"
- Use JavaScript to display the checkbox (or button/image)
- Use onkeydown/onkeypress to check if Caps Lock is on and, if so, display notice

A couple benefits from this scenario:
- saved passwords remain hidden by default (although, toggling the input field type would certainly reveal the plain-text password)
- the more "secure" option remains the default
- typos due to Caps Lock being accidentally turned on are reduced

I vote for the checkbox.

I agree a checkbox is almost unheard of and, from a usability standpoint, likely adds a level confusion that isn't acceptable for any application that is being used by the mainstream. I like the idea of having javascript that checks to see if caps locks is likely on...

i also like the iphone approach where you show the last letter typed in for a few moments, so that the user can tell if they've mistyped. that could be accomplished via javascript as well.

I agree with putting them in plaintext. A checkbox to mask is redundant and gives a false sense of security. Anyone who can see the screen can see the keyboard you are using to type on; and if you are intelligent enough to type in a manner that is hard to decipher then you are probably smart enough to use your hand to cover the password box as well.

A useful intermediate solution is to use AJAX to look up the username and then show either ****** or plaintext according to user preference (found via AJAX).

Sorry, I don't agree with any of this.

I don't store passwords in plain text, as a matter of fact I store them in one-way encryption so that hackers can't extract them.

Jakob Nielsen has some good ideas, but in this one it's an abysmal FAIL.

Passwords should be secure, unseen, and IMO encrypted in the browser with SSL so some some password sniffer can't get to your raw password.

When someone enters a password on my server it's immediately encrypted and the 2 encrypted versions are compared, the plain text never survives the POST operation.

If someone can't access the password, a reset password function linked to the email account solves this problem.

Therefore, your account is as secure as your email, and if your email is breached, that's a problem which is way worse than seeing your password in plain text.

incrediBILL, I think you may have the wrong end of the stick here. We are not discussing saving or transmitting the password as plaintext or otherwise; just the visual representation of the password field (whether every character should become an '*' as it is typed; or if perhaps the inconvenience of masking what is being typed outweighs the benefits of the stars.

I think that it should remain as it is. Seeing passwords blanked out re-enforces to the user that the password is an important thing and that it should not been seen by others. This makes many users pay more attention to protecting the password.

Also, we could begin to see people looking over at other folks screen to try and see their password. The fact that it doesn't happen often just now may well be done to the success of the hidden password system. Many people use the same password for all their popular sites - glancing at a screen and seeing one password could result in that person being able to access multiple websites.

And I do not think that being able to see passwords will result in better passwords being used. People are not going to start writing more cryptic passwords simply because they can now see what they are typing - they will continue to use short memorable passwords as complicated passwords are still too difficult to remember.

With all the people used to having their passwords masked when they type, most likely not masking them would lead to numerous phone calls/e-mail messages of outrage from users because their passwords aren't hidden any more.

I agree. I think that masked passwords have become such a well understood standard these days that doing anything else just "feels" insecure, regardless of the actual impact on security. And to be honest I would be concerned about people peeping over my shoulder.

So personally I think this is something that's unlikely to happen - I look forward to seeeing what happens when the first couple of commercial sites do it. I think they'd get plenty of negative feedback in regards to their security vs competitor X.

I also agree that adding a "mask my password" checkbox to the page is a usability nightmare. I can imagine my mum or my wife saying "what does this do then? I don't get this - I'm outta here". Users just want to know stuff is secure, not make decisions about security for themselves.

I agree with incredibill, "Passwords should be secure, unseen"

Nielsen is spot on as far as usability is concerned, but you have to sacrifice some usability to get security. There are simply too many places where people can see your password: open plan offices, public places (using mobile or wifi), even at home (if you do not want your children to have all your passwords), in shared accommodation.....

I would like to see a small change in the Password verification routines so that if the user enters a PW that's 90% correct then they should be let in. The remaining 10% is likely just typo's, upper/lower case, or a letter out of sequence.

I would like to see a small change in the Password verification routines so that if the user enters a PW that's 90% correct then they should be let in. The remaining 10% is likely just typo's, upper/lower case, or a letter out of sequence.

And which errors do you allow? Switched case? Addition of character, ommission of character, transposition of characters, hitting a nearby character.

If you allow all of those then, just allowing one mistake on 10 character password, you're suddenly allowing a hideous number of passwords to get through. It would greatly enhance the success of watching somebody type in their password. It would greatly enhance the success of dictionary attacks.

I'm with travelsite, a large amount of potential shoulder surfing probably doesn't happen at the moment because the password is starred out. You're not always in a position to watch somebody else type and it's easier to read the screen then watch a good touch typist type (I'm not that good and my stepsons tried to watch me type one password for two years with no success).

In one login application I built, I allowed for CAPS-LOCK to be on. If, on first pass, the password is judged to be incorrect, the script tries again with inverted case.

Perhaps there should also be a speaker button so the passwords can be spoken out to the users, after they have typed them in.

Perhaps there should also be a speaker button so the passwords can be spoken out to the users, after they have typed them in.

Or just a button "I don't know my password just now, let me proceed, I'll tell you next time I visit" ;)

I like the idea of javascript to check wether Caps Lock is on - can you also discover the key map, like Windows does in the Login screen, so you can switch key map layouts (german qwertz vs standard qwerty etc)?
If you can make sure it is well understood by the users, a "unmask password to check for typos" link might be fine. However, of course it's a security risk if your browser autofills the field.
That could be worked with by checking wether the password-field was blank onfocus and something has been typed.
I'm pretty good at typing my passwords, but sometimes I just miss a character or add one that shouldn't be there. My authorization gets recected, but I won't know if I used another password for this site or wether I spelled my password incorrectly. It's pretty much out of the question that someone is looking over my shoulder, so I'd be happy to use it.

I agree with Nielsen's premise, in this case. In fact the idea is nothing new, way back with text-based Unix terminals, we could "unmask" passwords by switching the terminal to half-duplex, then every key we typed was echoed to the screen as well as sent to the server, thereby letting us see the password which would otherwise be eaten. And as it's been pointed out, the technique makes users more comfortable with using longer passwords (e.g. more memorable phrases like a line from a favorite song). I too use Truecypt and love the "display password" option, it's the only place where i use a longish password.

BUT... expecting individual websites to implement this feature would NOT be the correct way of doing it, in fact it would be the worst way. One of the key criteria for usability is uniformity. If websites implement this individually, they'll all do it differently (not to mention waste time reinventing the wheel a gazillion times) causing unnecessary stress to the user. This is something that should be done at the browser level, and not just browsers but any application: OS login, email programs, everything. If done natively by the browser/application, then users will get used to it much more quickly and won't get alarmed because it's done by the browser and not some unknown, untrusted website.

A good browser would even have a preference to display/hide passwords by default, plus a control to toggle the display mode at the time of usage.

Same goes with caps lock detection, Windows pops up a warning at the login screen when caps lock is on, why not other applications, including the browsers? Again, it's not something we should implement over and over again with some Javascript kludge, it's something we should pressure browser makers to implement natively.

BTW, I don't quite agree with Nielsen and others who say "even today someone can steal your password by watching your keystrokes as you type it in." Yes but, that would require that person to actively watch every move you make from start to finish, if the password is displayed in plain-text, they only need to glance at the screen just as you finish typing it (or in case of websites, while you're waiting for the slow server to respond), big difference.

Finally, since it somewhat relates to this topic, i thought i'd risk the mods' wrath by posting one of my favorite bash entries: [bash.org...] :)

The silliness with the whole topic is that most people don't even bother typing in a password after the first time, they use their browser to remember the passwords or some other password vault.

Besides, do you really want your ATM or VISA pin code in plain text?

I didn't think so.

Besides, do you really want your ATM or VISA pin code in plain text?

that's a different thing. pin codes are generally very short. I wouldn't want anyone to know my card#, but I definetly don't want to have the input masked when entering 16 digits. 3 digits are probably not that hard for most people. But really, the question is not if it's useful for IT professionals, but for people who think the internet is built into their dsl modem and is produced by google.

I agree with idfer, solving it within the browser would be the cleanest solution (and it wouldn't even be that hard with greasemonkey etc), but how long will that take?

BTW, I don't quite agree with Nielsen and others who say "even today someone can steal your password by watching your keystrokes as you type it in." Yes but, that would require that person to actively watch every move you make from start to finish...

Quite some years ago, I was in class with some other students, and we were discussing passwords. I had seen some of the characters one guy typed in for a password, when I realized this guy had a motor bike, and the characters I'd seen could be part of a particular bike brand name. So, as we were discussing passwords, I asked him what brand motor bike he had. Without answering, he rushed off to his computer ... to change his password.

It's not necessarily hard to guess someone's password from seeing some of the characters they type in, if you know a little of them. People use passwords they can remember easily.

And then, if you're really intent on getting a password from someone at a computer, it is possible to pick up signals from keyboards remotely, and construct characters from these.

Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they're using an Internet cafe. It's therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there's a tension between security and usability, sometimes security should win.

I have often thought of this behavior as well. Where I become fearful is with "auto complete" and "remember/prefill my text box" that many browsers offer. It takes a savy user to make sure their plain text tracks are covered and most users still don't meet my "savy" designation.

I would like to see a small change in the Password verification routines so that if the user enters a PW that's 90% correct then they should be let in. The remaining 10% is likely just typo's, upper/lower case, or a letter out of sequence.

Oh my no.

My position has always been, if a username and password is too confusing for you to use properly it is most likely that the area they give you access to is equally or more complicated and you require training to use a computer.

If info is important enough to protect, then you might as well protect it properly.

Making logging in easier for people who mis-type and forget their passwords is like making a door locking mechanism easy to open when you forget your key.

What's the point of the lock then?

Imagine if your house keys had a 10% allowance for malformed keys, you in case you get a nick in the metal.

Crazy talk

[edited by: Demaestro at 8:23 pm (utc) on July 6, 2009]

OK here's some crazy talk.

There are tools to spy on anything that's diplayed on a computer monitor LCD or CRT. Watching from start to finish is possible. Some governments spend considerable amounts to prevent such spying, but nothing in the commercial markets.

Isn't it interesting how passwords are generally typed in using **** or ••••, while credit card numbers and, especially, CVV2 codes are not.

Non-obfuscated password fields are no less secure than the ****/•••• versions. The security comes from how the data is transmitted.

Security through obscurity ...

The only problem I would see with making the password fields plain-text is users freaking out about a non-issue.

In reality, whether a password (or credit card number) is obscured through asterisks/dots does not matter one bit while the data is being typed. It matters, however, when the data is being returned to the user. Obviously, a password/CC#/CVV2 should never be repopulated/returned to the user. But while they are typing, there is very little security concern.

Nielson says -

there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

But then, in the very next line -

Password masking has proven to be a particularly nasty usability problem in our testing of mobile devices, where typing is difficult and typos are common.

But, But, Here's exactly the spot where masking is really needed. Users are not alone in their offices anymore!

On the other hand, I agree with his usability assessment of the login and verification process. There's lots and lots of room for improvement in all sorts of areas. And I personally make many mistakes typing on handheld devices. It's maddening.

So, speaking as a user and not a usability guru, I think the idea of a checkbox might be good, but it should require checking to make the password visible, and that checkbox should revert to masked default every time the page is refreshed, the window is closed, or the browser shut down.If it stays on, the user will forget in public on their handheld.

Also, idfer's point that it should become application standard, and not implemented website by website is important.

Personally, I think the solution is going to have to include some kind of easy and secure password storage and retrieval systems. We are all accumulating an unmanageable number of usernames, passwords, and interfaces where these are required, just to go about our daily lives.

[edited by: commanderW at 8:45 am (utc) on July 7, 2009]