The phrase “it may possibly someday contain potentially sensitive data” is the most lame excuse for including passwords. Especially for sites that have open registration. Each time I see a forum or other website that requires you to register just to:
see the site
search on the site
display images
download attachments
provide feedback
I think something went really wrong. Most of the time it’s just the site admin who either blindly follows the example of others, does’t really care about the users and wants to limit traffic by all costs or simply leaves the silly default settings on. There are also those “if they want to see my site I want their e-mail address first” types, but that qualifies for therapy—most of those addresses will be single-use spam pits anyways.
If you really need to protect sensitive data, don’t put it on the internet in the first place. If plan to base the protection of this data on the trust and reliability of your users working hard to keep your site safe, you are going to be very disappointed. And it’s not really because it’s so hard to remember a password or to think of a good password recovery question. It’s simply because they don’t care about your site, and the more you are going to force them into working for you on this—by using password quality checkers (which, by the way, only make the passwords easier to guess by narrowing the pool), captchas, forcing password changes and such—the more they will resist and may even actively rebel—for example by posting the password on bugmenot.
Most of the time you can give up the whole registration process and password and just let people do their work. Especially if you expect them to collaborate with you. And no, they don’t really need those custom user preferences, timezone, avatar and history of recent searches. And even if they do, you don’t really have to protect them with a password. Especially since 99% of your users won’t even bother to change the defaults. They won’t even bother to log in again with the same username, probably.
Really, think twice, because often there is just a little change in your planning required to get rid of the passwords, at least from the most of your site.
By the way, the security experts are probably going to hate me for this, but I honestly think that a single shared password is a great thing for small, closely collaborating groups. If somebody forgets it, others will remind. Of course, you have to change it if it leaks, that’s why it only works for small groups.
Copy & paste the code below to embed this comment.
Catherine Williams
An article about passwords that requires one to log in to comment? It has taken me 10 minutes to do so because:
I forgot the username, password, and email address I used to register
In order to retrieve my password, I had to try several email addresses; every email address that was not in A List Apart’s database generated this charming error message:
“Database Error: Unable to connect to your database. Your database appears to be turned off or the database connection settings in your config file are not correct. Please contact your hosting provider if the problem persists.”
When I finally remembered which email address I’d used, ALA sent me two reset requests. The first one sent to me generated the same “Database Error” message
ALA then emailed me my username and new password in the clear
Perfect illustration of some of the points made above, that is, requiring login for relatively trivial things is:
frustrating to users, who have to remember many dozens of username / password / email combinations if they are attempting to be at all security-conscious
completely pointless if you are going to email complete login details
I’d also second the point that passwords should be allowed to be long enough that we can use phrases or complete sentences as passwords, preferably with punctuation and phrasing. Nothing more frustrating than trying to enter a memorable, long, complex password to be told something along the lines of “only 12 letters/numbers allowed”.
Stop requiring logins for trivial tasks, and make it easier to have long, memorable passwords. Thereby reduce the need to expose letters somehow during password entry, with all the attendant problems of reduced user confidence and increased chance of shoulder surfing.
Copy & paste the code below to embed this comment.
Chibu
@Catherine Williams: There are problems with not needing to login to post comments. Obviously, there are spambots. But as many other sites have noticed, and personally I agree, allowing anonymous comments is just asking for trolls and posts that are, well, mean. I personally agree with the need to have an account and login to comment on a post. And sure they’ll email you your login info; they’re assuming that the email address that you gave them is an account only used by you, so what’s the harm?
I definately agree about password length though. I’ve been using variations of a randomly generated password (that i was given by some site years ago…) for awhile now. The passwords based on this are easy for me to remember, because i’ve been using them so long, but many sites will only allow short passwords. I’ve seen “Between 6 and 8 characters” and the worst password system I’d ever seen was: “Your password must be exactly 8 characters including at least 1 number”…
Personally (as a web developer like most of you probably are), I can see no good reason to limit the length of passwords so much. I can understand needing a limit, but 64 or 128 characters wouldn’t really slow down a login/users database. More importantly, for sites that do not email you your password, there’s no reason not to keep only a hash of it, therefore making the actual length irrelevant.
In response to tddewey (#4), I agree that some things are better left to the browser. Although it’s easy to understand the need to use JavaScript to mimic more desirable behavior, it’s generally a lot more overhead than it’s worth, even if you’re using a library.
Coincidentally, the second demo doesn’t show the cursor in Firefox 3.6/Mac (not on focus nor as you type). This is a prime example of the overhead that I’m talking about: The “solution” has introduced another usability issue that, in my opinion as a user, outweighs the initial problem. Good luck spending hours troubleshooting things like this on all browsers/platforms.
Not to say it’s a bad idea, but it’s better left to the browser to handle. Not only will the functionality work properly, but users will be able to set their preferences while having consistent behavior on all websites, not just one.
If anything, this is something that the HTML 5 draft should be looking at.
For this technique to be effective in the wild, the implementation must have the same functionality as the original, but with the added benefit of self-validation. I believe that somehow implementing synchronised feedback between both the mask layer and the input layer (when highlighting) is essential in ensuring a usable improvement to the password field.“service directory”:http://www.myservicemonster.com/ There is either an issue masking the text or there isn’t. If there is, then half-masking or toggle-masking isn’t a solution — it adds another layer of complexity to the interface. The only real solution is clear text (which I personally agree with). n addition to the two methods listed, the only other suggestion that I can give to help users input their passwords correctly is to warn them that caps lock is on. Sadly we can’t do this until the user actually presses a button. I think web designers/developers should do their part and make the site as secure as possible, everything else is the users responsibility.
Copy & paste the code below to embed this comment.
Catherine Williams
@Chibu
“And sure they’ll email you your login info; they’re assuming that the email address that you gave them is an account only used by you, so what’s the harm?”
Um. Emailed usernames and passwords can easily be intercepted without anyone hacking your email account: packet sniffers make unencrypted email about as secure as sending snail mail by handing an unsealed envelope to a random passer by and asking them to pass it on. Hence the recommendation never to send a credit card number, social security number, bank account details etc via email.
Good point about wanting to forestall comments by trolls, flamers, spammers etc. Requiring login doesn’t deter all such problems, though. Someone determined can just make new accounts (and account creation can be automated: a problem I’ve seen on a wiki recently). There are other ways to prevent such issues (moderation, captchas, automatic filtering for “banned” terms, etc), although admittedly these all have flaws too.
One further issue with password security that I’ve encountered: it’s all too easy to type a password into the wrong box or the wrong window. When you’re concentrating on entering every character correctly, you tend to be looking at the keyboard, not the screen. Thus, you don’t always notice that the focus is in / has shifted to the wrong place. This happened to me yesterday, when entering a chatroom password: my client popped up a window for me to enter the password but didn’t automatically move the focus there. Instead, the focus remained in the chatroom. I didn’t notice: I just typed in the password and pressed “enter”…. so ended up sending my password to the world. Since I make sure to have completely different user names and passwords for every account, this wasn’t too big a deal, but it was still a hassle to have to scurry around to reset it.
Copy & paste the code below to embed this comment.
dave8513
@samadamssmith et al.
If you use MooTools (I just love MooTools: mootools.net), a great and easy way to check for caps lock is to use the Caps Lock plugin found on the MooTools forge:
CapsLock @ http://mootools.net/forge/p/capslock
Known Issues:
Since CapsLock has to first sniff the state of the caps lock key, there can be a delay between user input being able to provide feedback via the events. Specifically, until there is a keypress event where the user types in a lowercase letter with shift pressed down or they type in an uppercase letter without shift, these events won’t fire.
Additionally, if the user un-focuses the window and comes back, we have no way of knowing if the caps lock state was changed during that time so CapsLock resets its state when this happens to ensure no false positives so a re-sniffing will be done.
In practice though, users will type in their username or other data first which will establish the state of the caps lock before moving on to the password field where these events are most useful. This means there will be no discernible delay on the user’s side and will allow you to provide accurate visual feedback.
Copy & paste the code below to embed this comment.
heywood
There’s a nice solution if you have a site with users that mistype their passwords all the time (If you do not, then I’d argue this solution overkill.):
You devise a small script that takes the content of the password-field and generates a digested string from it. (By for instance using MD5.) You use this string to construct a small graphic, for instance 3 bars with different colors. You make it so the colors of the bars are created from the digisted string. The bars are shown every time a user types a password. After a while the user learns how “his/hers” bars look when the password is typed correctly and it becomes second-nature. Because MD5 generates very different outputs from even single character changes, the bars will look very different if you mistype your password, and the user will feel that something is wrong.
You can see this is action here: letsmix.com (click Login and try a user/password)
But as I said, unless you actually have a problem with people mistyping passwords all the time, I’d say it just adds noise. Your users also need to be smart to pick up on it, which, well…
Otherwise, I subscribe to the idea that showing passwords in clear-text is fundamentally wrong.
Copy & paste the code below to embed this comment.
olaim
The two form examples in the article just show how demasking a password would typically look like. They don’t demonstrate how browsers actually act when you submit logon details to a web site.
Since example one basically changes a password field to a text field, the following security and usability issues emerge once the user submits her password after choosing to see it in plain text:
Since the browser doesn’t see a password field, it doesn’t ask the user whether she wants to save it upon submitting.
And what is worse: The next user on the same computer can enter the previous one’s user name in the user name field, tick the `Show password’ box and double click in the password field. Most browsers will reveal the previous user’s password – in plain text. A web developer can not let this happen!
On my blog I have posted an example where we keep the visual design of the original example one, but still let browsers understand that the password being typed is a password, and thus continue password-handling in their usual way.
So how is this done? Well, approximately like this:
When the user checks the `Show password’ box, a new, empty text field is created, and the original password field is hidden behind the new field.
As the user types her password in plain text, the input in the new field will will be inserted in the invisible, original password field.
When the user submits her data, or chooses to not show her password anymore, the text field with the password disappears (for good).
On my blog you can test example youself. Go ahead and read it on “http://www.imers.no/passwords-no-problem”:http://www.imers.no/passwords-no-problem
@olaim, the only problem I have with using a separate text field is that because it needs its own unique name and ID, it won’t inherit ID-based CSS or JavaScript, so it’s less transparent in that way.
Several comments, though, seem to think that revealing the password in plain text somehow creates a security problem. The fact is that it’s stored that way in the DOM anyway. JavaScript can read it, and it’s transmitted as text in the HTTP request (which will hopefully be encrypted using SSL/TLS). I maintain that the only threat model masking protects against is physical observation. Dots in a form are not encryption.
As far as autocomplete goes, it can be disabled by code as well (beyond the scope of my demonstration). A public/shared computer shouldn’t have it turned on anyway, as we’re likely to type all sorts of sensitive data into non-password text fields (credit card numbers for example).
I agree making passwords clear text or will help security or people remember passwords, the options mentioned do help people remember.
A great example is Media Temple’s account pages. There are multiple passwords I manage for my account such as FTP, email, and my over all system password. If I forget a password I would have to reset it. BUT Media Temple gives me the option to show my password in clear text, keeping me from reseting it.
Virgin Credit card use a novel method of seperation; forcing the user to enter a username, then on the second page asking for a password. Not bulletproof but it would slow down any script used in bruteforce hacking.
Out of the examples provided I prefer #1 as I can see that people at home using their PC’s would care more about being able to log in correctly then someone in the household seeing their password. It’s an odd UX challenge when you consider that password hashing has been present in software since the 70s and people are very much used to it, so I cant see a huge advantage to modifying the default password hashing behaviour.
I agree that the ‘iPhone’ method is a good idea and could improve user experience when logging into a site. My only problem here is that Apple didn’t invent this. It has been around on mobile devices for years before the iPhone even existed (Windows Mobile, to give one example).
Copy & paste the code below to embed this comment.
Stephen Down
Echoing the comments raised above, the irony is that ALA fails dismally in password management. For some reason the username and password I used to use stopped working and I now have a new username and password that I can’t remember. So I have had to request a new password, which I won’t be able to remember, and I can’t see any way to change it to one that I will remember. So every time I want to comment on an article I will have to go through the same wretched process.
Password restrictions are far too complex. Many sites require people to register, even though there is no good reason for doing so. Many sites that need passwords have particular requirements, in terms of length of password and type of characters – some can only include letters and numbers, some must use capital and lower case, some must include non-alphanumeric symbols – all of which means that users have to use multiple different passwords, which significantly increases the chance of them failing to remember the right password, or choosing a password that is blatantly guessable.
As for Nielsen’s suggestion of putting passwords in plain-text – no, no and no! I did email Nielsen the day after he wrote that article to point out a number of usability flaws in his plan, but of course there has been no response or follow-up, as his articles are the gospel truth from the one true guru and are not susceptible to suggestions or improvements by mortal plebs like the rest of us (sorry, rant over)…
Firstly – security concerns. Passwords have been masked since time immemorial because it prevents other people standing nearby from reading them. Allowing them in plain text would be criminally negligent in terms of exposing accounts to hacking. You might as well just write a list of all your passwords on a piece of paper and stick it to your monitor. I can see the argument for allowing plain text on a device like an iPhone that can’t easily be seen by other people, but on a normal monitor, it is totally unacceptable.
Secondly – usability. When I am logging into a website, I know that what I see in plain text is my username, and when I see a string of asterisks or blobs then I’m typing my password. That is a valuable visual cue, and can help prevent instances like the one where a previous contributor typed their password into a chat box. People are used to the way logins work now, and changing it would raise a number of problems while offering minimal benefits.
<div>Those are good scripts, but there’s a little bug in the second alternative script.
In the part that says:var input = inputs;
It should say:var input = password_inputs;
The original will break when there are input elements other than password.
</div>
I can’t wait until all sites implement “show password” checkbox, so I’ve made “Show Password on Focus”:http://github.com/NV/show-password-on-focus.js (“Chrome extension”:https://chrome.google.com/extensions/detail/ogjaejebjmifpkiaafdnnpkkjnmopmhn and “user script”:http://userscripts.org/scripts/show/68664 ).
Copy & paste the code below to embed this comment.
olgalednichenko
Am I the only one – who cant remember brazillions of userids and passwords?
Guy kawasaki blogged last year – about web sites expecting one to remmeber all sorts of permutations and combinations: oh this doesnt take – here its user name !!
and well, there is another annoying thing aside from hacks and what else..:
its verify and then the captcha
and while i am at it:
can someone break the news to lemondrop – verifying every comment – via a click to email = bad karma on the net
Copy & paste the code below to embed this comment.
Aristos
I have test it and work very well, and its a very nice idea.
The only think I like to notice is that you can check if the password is allready there by the browser, and if it is do not show the button, because then its easy for some tried person to see it in a second.
So add this line if(input.value == “”) to not show anything if the password exist there from the browser.
Copy & paste the code below to embed this comment.
olaim
@Aristos: To disable the `Show password’-button if the browser pre-fills it for you, is a good idea. But it still means that a person sitting next to you could see the password you have just typed into that field, if he is quick (and a not so good friend).
What I proposed in my former post will prevent this from happening:
1. When the user checks the `Show password’ box, a new, empty text field is created, and the original password field is hidden behind the new field.
Then no one will ever see what anyone (else) has written in the password field.
The idea of having clear text passwords may be alright if I’m working on my home pc but if that was the web standard then User accounts would be getting hacked left,right and centre.
The idea to toggle between the two is okay but involves more code and maybe over complicates the login process however admittedly I have used the feature on my router before.
Personally I think a less secure easy to remember password is better than having only a clear text password input field, but I would personally always recommend using strong passwords and having them hidden from view.
Copy & paste the code below to embed this comment.
bloritsch
Any time you use JavaScript to access and store passwords, you are demonstrating what any advertiser can do on your site. Truly, the only reason why the user name/password combination is in prevalent use today is because it is easy to implement. Other options that are arguably more secure such as PKI (caveats with that as well) and biometrics are notoriously difficult to do on the web.
I like the concept of OpenID, which provides some creative ways around the whole user name/password concept. For example, the people at “My OpenID” (myopenid.com) provide an option to generate a key that is specific to your browser. As long as your browser has that key and you have the password to that key you can get into any website that supports the OpenID protocol. Of course, this presents problems with internet cafes.
The real solution is to find something other than arcane passwords to protect access to the site, that still gives both the web site and the user a high confidence level. A real solution will also address site spoofing (phishing attempts) which is a real problem.
Any solution that allows access to what I typed through JavaScript demonstrates just how easy it is to steal credentials. To all web designers: do not allow advertising on any page that takes in passwords. It is too easy to accidentally include malicious ads, and even in HTML 5 there is no appropriate sand-boxing of content that originates from other servers.
There are obvious usability issues with not being able to see the password you are typing. There are also times where it would be more practical to just see a password in an admin panel rather than have to reset it. There’s no rational reason why a person signing into their “A List Apart” account from their own office shouldn’t be able to see the password as they are typing it.
Regardless of this, making this information visible might draw complaints from users because it is different from their expectations. There are also many times when the highest level of security is critical.
Having a “View your password as you type” link is a no-brainer for non-senisitive logins. It allows the user to judge whether they feel secure in their environment. Additionally, a popup layer could provide additional instructions “Use this if you are in a private location.”
Taking responsibility for this, improves the success of the site. So why leave it to the browser or os. Most users will not know how to use these features anyway.
46 Reader Comments
Back to the Articledassheep
The phrase “it may possibly someday contain potentially sensitive data” is the most lame excuse for including passwords. Especially for sites that have open registration. Each time I see a forum or other website that requires you to register just to:
I think something went really wrong. Most of the time it’s just the site admin who either blindly follows the example of others, does’t really care about the users and wants to limit traffic by all costs or simply leaves the silly default settings on. There are also those “if they want to see my site I want their e-mail address first” types, but that qualifies for therapy—most of those addresses will be single-use spam pits anyways.
If you really need to protect sensitive data, don’t put it on the internet in the first place. If plan to base the protection of this data on the trust and reliability of your users working hard to keep your site safe, you are going to be very disappointed. And it’s not really because it’s so hard to remember a password or to think of a good password recovery question. It’s simply because they don’t care about your site, and the more you are going to force them into working for you on this—by using password quality checkers (which, by the way, only make the passwords easier to guess by narrowing the pool), captchas, forcing password changes and such—the more they will resist and may even actively rebel—for example by posting the password on bugmenot.
Most of the time you can give up the whole registration process and password and just let people do their work. Especially if you expect them to collaborate with you. And no, they don’t really need those custom user preferences, timezone, avatar and history of recent searches. And even if they do, you don’t really have to protect them with a password. Especially since 99% of your users won’t even bother to change the defaults. They won’t even bother to log in again with the same username, probably.
Really, think twice, because often there is just a little change in your planning required to get rid of the passwords, at least from the most of your site.
By the way, the security experts are probably going to hate me for this, but I honestly think that a single shared password is a great thing for small, closely collaborating groups. If somebody forgets it, others will remind. Of course, you have to change it if it leaks, that’s why it only works for small groups.
Catherine Williams
An article about passwords that requires one to log in to comment? It has taken me 10 minutes to do so because:
“Database Error: Unable to connect to your database. Your database appears to be turned off or the database connection settings in your config file are not correct. Please contact your hosting provider if the problem persists.”
Perfect illustration of some of the points made above, that is, requiring login for relatively trivial things is:
I’d also second the point that passwords should be allowed to be long enough that we can use phrases or complete sentences as passwords, preferably with punctuation and phrasing. Nothing more frustrating than trying to enter a memorable, long, complex password to be told something along the lines of “only 12 letters/numbers allowed”.
Stop requiring logins for trivial tasks, and make it easier to have long, memorable passwords. Thereby reduce the need to expose letters somehow during password entry, with all the attendant problems of reduced user confidence and increased chance of shoulder surfing.
spaceandtime
I like both options but think I would go with option 2. The user wont have to do anything different.
Chibu
@Catherine Williams: There are problems with not needing to login to post comments. Obviously, there are spambots. But as many other sites have noticed, and personally I agree, allowing anonymous comments is just asking for trolls and posts that are, well, mean. I personally agree with the need to have an account and login to comment on a post. And sure they’ll email you your login info; they’re assuming that the email address that you gave them is an account only used by you, so what’s the harm?
I definately agree about password length though. I’ve been using variations of a randomly generated password (that i was given by some site years ago…) for awhile now. The passwords based on this are easy for me to remember, because i’ve been using them so long, but many sites will only allow short passwords. I’ve seen “Between 6 and 8 characters” and the worst password system I’d ever seen was: “Your password must be exactly 8 characters including at least 1 number”…
Personally (as a web developer like most of you probably are), I can see no good reason to limit the length of passwords so much. I can understand needing a limit, but 64 or 128 characters wouldn’t really slow down a login/users database. More importantly, for sites that do not email you your password, there’s no reason not to keep only a hash of it, therefore making the actual length irrelevant.
claviska
In response to tddewey (#4), I agree that some things are better left to the browser. Although it’s easy to understand the need to use JavaScript to mimic more desirable behavior, it’s generally a lot more overhead than it’s worth, even if you’re using a library.
Coincidentally, the second demo doesn’t show the cursor in Firefox 3.6/Mac (not on focus nor as you type). This is a prime example of the overhead that I’m talking about: The “solution” has introduced another usability issue that, in my opinion as a user, outweighs the initial problem. Good luck spending hours troubleshooting things like this on all browsers/platforms.
Not to say it’s a bad idea, but it’s better left to the browser to handle. Not only will the functionality work properly, but users will be able to set their preferences while having consistent behavior on all websites, not just one.
If anything, this is something that the HTML 5 draft should be looking at.
samadamssmith
For this technique to be effective in the wild, the implementation must have the same functionality as the original, but with the added benefit of self-validation. I believe that somehow implementing synchronised feedback between both the mask layer and the input layer (when highlighting) is essential in ensuring a usable improvement to the password field.“service directory”:http://www.myservicemonster.com/ There is either an issue masking the text or there isn’t. If there is, then half-masking or toggle-masking isn’t a solution — it adds another layer of complexity to the interface. The only real solution is clear text (which I personally agree with). n addition to the two methods listed, the only other suggestion that I can give to help users input their passwords correctly is to warn them that caps lock is on. Sadly we can’t do this until the user actually presses a button. I think web designers/developers should do their part and make the site as secure as possible, everything else is the users responsibility.
Catherine Williams
@Chibu
“And sure they’ll email you your login info; they’re assuming that the email address that you gave them is an account only used by you, so what’s the harm?”
Um. Emailed usernames and passwords can easily be intercepted without anyone hacking your email account: packet sniffers make unencrypted email about as secure as sending snail mail by handing an unsealed envelope to a random passer by and asking them to pass it on. Hence the recommendation never to send a credit card number, social security number, bank account details etc via email.
Good point about wanting to forestall comments by trolls, flamers, spammers etc. Requiring login doesn’t deter all such problems, though. Someone determined can just make new accounts (and account creation can be automated: a problem I’ve seen on a wiki recently). There are other ways to prevent such issues (moderation, captchas, automatic filtering for “banned” terms, etc), although admittedly these all have flaws too.
One further issue with password security that I’ve encountered: it’s all too easy to type a password into the wrong box or the wrong window. When you’re concentrating on entering every character correctly, you tend to be looking at the keyboard, not the screen. Thus, you don’t always notice that the focus is in / has shifted to the wrong place. This happened to me yesterday, when entering a chatroom password: my client popped up a window for me to enter the password but didn’t automatically move the focus there. Instead, the focus remained in the chatroom. I didn’t notice: I just typed in the password and pressed “enter”…. so ended up sending my password to the world. Since I make sure to have completely different user names and passwords for every account, this wasn’t too big a deal, but it was still a hassle to have to scurry around to reset it.
dave8513
@samadamssmith et al.
If you use MooTools (I just love MooTools: mootools.net), a great and easy way to check for caps lock is to use the Caps Lock plugin found on the MooTools forge:
CapsLock @ http://mootools.net/forge/p/capslock
Known Issues:
Since CapsLock has to first sniff the state of the caps lock key, there can be a delay between user input being able to provide feedback via the events. Specifically, until there is a keypress event where the user types in a lowercase letter with shift pressed down or they type in an uppercase letter without shift, these events won’t fire.
Additionally, if the user un-focuses the window and comes back, we have no way of knowing if the caps lock state was changed during that time so CapsLock resets its state when this happens to ensure no false positives so a re-sniffing will be done.
In practice though, users will type in their username or other data first which will establish the state of the caps lock before moving on to the password field where these events are most useful. This means there will be no discernible delay on the user’s side and will allow you to provide accurate visual feedback.
heywood
There’s a nice solution if you have a site with users that mistype their passwords all the time (If you do not, then I’d argue this solution overkill.):
You devise a small script that takes the content of the password-field and generates a digested string from it. (By for instance using MD5.) You use this string to construct a small graphic, for instance 3 bars with different colors. You make it so the colors of the bars are created from the digisted string. The bars are shown every time a user types a password. After a while the user learns how “his/hers” bars look when the password is typed correctly and it becomes second-nature. Because MD5 generates very different outputs from even single character changes, the bars will look very different if you mistype your password, and the user will feel that something is wrong.
You can see this is action here: letsmix.com (click Login and try a user/password)
But as I said, unless you actually have a problem with people mistyping passwords all the time, I’d say it just adds noise. Your users also need to be smart to pick up on it, which, well…
Otherwise, I subscribe to the idea that showing passwords in clear-text is fundamentally wrong.
olaim
The two form examples in the article just show how demasking a password would typically look like. They don’t demonstrate how browsers actually act when you submit logon details to a web site.
Since example one basically changes a password field to a text field, the following security and usability issues emerge once the user submits her password after choosing to see it in plain text:
On my blog I have posted an example where we keep the visual design of the original example one, but still let browsers understand that the password being typed is a password, and thus continue password-handling in their usual way.
So how is this done? Well, approximately like this:
On my blog you can test example youself. Go ahead and read it on “http://www.imers.no/passwords-no-problem”:http://www.imers.no/passwords-no-problem
Lyle Mullican
@olaim, the only problem I have with using a separate text field is that because it needs its own unique name and ID, it won’t inherit ID-based CSS or JavaScript, so it’s less transparent in that way.
Several comments, though, seem to think that revealing the password in plain text somehow creates a security problem. The fact is that it’s stored that way in the DOM anyway. JavaScript can read it, and it’s transmitted as text in the HTTP request (which will hopefully be encrypted using SSL/TLS). I maintain that the only threat model masking protects against is physical observation. Dots in a form are not encryption.
As far as autocomplete goes, it can be disabled by code as well (beyond the scope of my demonstration). A public/shared computer shouldn’t have it turned on anyway, as we’re likely to type all sorts of sensitive data into non-password text fields (credit card numbers for example).
gtim19
I agree making passwords clear text or will help security or people remember passwords, the options mentioned do help people remember.
A great example is Media Temple’s account pages. There are multiple passwords I manage for my account such as FTP, email, and my over all system password. If I forget a password I would have to reset it. BUT Media Temple gives me the option to show my password in clear text, keeping me from reseting it.
Great article!
Chris McKee
Virgin Credit card use a novel method of seperation; forcing the user to enter a username, then on the second page asking for a password. Not bulletproof but it would slow down any script used in bruteforce hacking.
Out of the examples provided I prefer #1 as I can see that people at home using their PC’s would care more about being able to log in correctly then someone in the household seeing their password. It’s an odd UX challenge when you consider that password hashing has been present in software since the 70s and people are very much used to it, so I cant see a huge advantage to modifying the default password hashing behaviour.
jdeerhake
I agree that the ‘iPhone’ method is a good idea and could improve user experience when logging into a site. My only problem here is that Apple didn’t invent this. It has been around on mobile devices for years before the iPhone even existed (Windows Mobile, to give one example).
Stephen Down
Echoing the comments raised above, the irony is that ALA fails dismally in password management. For some reason the username and password I used to use stopped working and I now have a new username and password that I can’t remember. So I have had to request a new password, which I won’t be able to remember, and I can’t see any way to change it to one that I will remember. So every time I want to comment on an article I will have to go through the same wretched process.
Password restrictions are far too complex. Many sites require people to register, even though there is no good reason for doing so. Many sites that need passwords have particular requirements, in terms of length of password and type of characters – some can only include letters and numbers, some must use capital and lower case, some must include non-alphanumeric symbols – all of which means that users have to use multiple different passwords, which significantly increases the chance of them failing to remember the right password, or choosing a password that is blatantly guessable.
As for Nielsen’s suggestion of putting passwords in plain-text – no, no and no! I did email Nielsen the day after he wrote that article to point out a number of usability flaws in his plan, but of course there has been no response or follow-up, as his articles are the gospel truth from the one true guru and are not susceptible to suggestions or improvements by mortal plebs like the rest of us (sorry, rant over)…
Firstly – security concerns. Passwords have been masked since time immemorial because it prevents other people standing nearby from reading them. Allowing them in plain text would be criminally negligent in terms of exposing accounts to hacking. You might as well just write a list of all your passwords on a piece of paper and stick it to your monitor. I can see the argument for allowing plain text on a device like an iPhone that can’t easily be seen by other people, but on a normal monitor, it is totally unacceptable.
Secondly – usability. When I am logging into a website, I know that what I see in plain text is my username, and when I see a string of asterisks or blobs then I’m typing my password. That is a valuable visual cue, and can help prevent instances like the one where a previous contributor typed their password into a chat box. People are used to the way logins work now, and changing it would raise a number of problems while offering minimal benefits.
tiangolo
<div>Those are good scripts, but there’s a little bug in the second alternative script.
In the part that says:var input = inputs;
It should say:var input = password_inputs;
The original will break when there are input elements other than password.
</div>
tiangolo
Ups! (it appears that HTML doesn’t render as source code as said in the comments form)var foo; //The “<pre>” tags shouldn’t appear
Usability Student
I like the idea with the checkbox behind it but it will make your form realy wide.
BTW in example2 if you type fast you will not see your last char. (or at least in chrome.)
Ð?икита ВаÑ?ильев
I can’t wait until all sites implement “show password” checkbox, so I’ve made “Show Password on Focus”:http://github.com/NV/show-password-on-focus.js (“Chrome extension”:https://chrome.google.com/extensions/detail/ogjaejebjmifpkiaafdnnpkkjnmopmhn and “user script”:http://userscripts.org/scripts/show/68664 ).
olgalednichenko
Am I the only one – who cant remember brazillions of userids and passwords?
Guy kawasaki blogged last year – about web sites expecting one to remmeber all sorts of permutations and combinations: oh this doesnt take – here its user name !!
and well, there is another annoying thing aside from hacks and what else..:
its verify and then the captcha
and while i am at it:
can someone break the news to lemondrop – verifying every comment – via a click to email = bad karma on the net
cheers, regards and regrets
olga-nesher-lednichenko
Aristos
I have test it and work very well, and its a very nice idea.
The only think I like to notice is that you can check if the password is allready there by the browser, and if it is do not show the button, because then its easy for some tried person to see it in a second.
So add this line if(input.value == “”) to not show anything if the password exist there from the browser.
if(input.type ‘password’) {
if(input.value “”)
{
olaim
@Aristos: To disable the `Show password’-button if the browser pre-fills it for you, is a good idea. But it still means that a person sitting next to you could see the password you have just typed into that field, if he is quick (and a not so good friend).
What I proposed in my former post will prevent this from happening:
Then no one will ever see what anyone (else) has written in the password field.
WebDesignMidlands
The idea of having clear text passwords may be alright if I’m working on my home pc but if that was the web standard then User accounts would be getting hacked left,right and centre.
The idea to toggle between the two is okay but involves more code and maybe over complicates the login process however admittedly I have used the feature on my router before.
Personally I think a less secure easy to remember password is better than having only a clear text password input field, but I would personally always recommend using strong passwords and having them hidden from view.
bloritsch
Any time you use JavaScript to access and store passwords, you are demonstrating what any advertiser can do on your site. Truly, the only reason why the user name/password combination is in prevalent use today is because it is easy to implement. Other options that are arguably more secure such as PKI (caveats with that as well) and biometrics are notoriously difficult to do on the web.
I like the concept of OpenID, which provides some creative ways around the whole user name/password concept. For example, the people at “My OpenID” (myopenid.com) provide an option to generate a key that is specific to your browser. As long as your browser has that key and you have the password to that key you can get into any website that supports the OpenID protocol. Of course, this presents problems with internet cafes.
The real solution is to find something other than arcane passwords to protect access to the site, that still gives both the web site and the user a high confidence level. A real solution will also address site spoofing (phishing attempts) which is a real problem.
Any solution that allows access to what I typed through JavaScript demonstrates just how easy it is to steal credentials. To all web designers: do not allow advertising on any page that takes in passwords. It is too easy to accidentally include malicious ads, and even in HTML 5 there is no appropriate sand-boxing of content that originates from other servers.
Michael Levy
There are obvious usability issues with not being able to see the password you are typing. There are also times where it would be more practical to just see a password in an admin panel rather than have to reset it. There’s no rational reason why a person signing into their “A List Apart” account from their own office shouldn’t be able to see the password as they are typing it.
Regardless of this, making this information visible might draw complaints from users because it is different from their expectations. There are also many times when the highest level of security is critical.
Having a “View your password as you type” link is a no-brainer for non-senisitive logins. It allows the user to judge whether they feel secure in their environment. Additionally, a popup layer could provide additional instructions “Use this if you are in a private location.”
Taking responsibility for this, improves the success of the site. So why leave it to the browser or os. Most users will not know how to use these features anyway.
lsoares
function togglePassword(elementId, showText) {
var newPasswordField = $(elementId).clone(true);
$(newPasswordField).attr(‘type’ , showText ? ‘text’ : ‘password’);
$(elementId).replaceWith(newPasswordField);
}