On password fields masking and Jakob Nielsen
Jakob Nielsen just posted on alertbox that we should stop password masking (you know, showing asterisks or dots instead of showing the password while the user types it in.
His argument is the following:
Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users’ shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn’t even protect fully against snoopers.
More importantly, 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.
Which makes me wonder when was the last time that Mr.Nielsen left his house to communicate with the real world. As a frequent traveller I am constantly seeing people logging into web sites in hotel lobbies (when they check in for their flight for example and enter their bonus miles account details), in Internet Cafes or when they use their laptop in a public space. While it is harder to spot the keyboard (especially with fast typers) there is no problem whatsover looking over their shoulder or – using my 10x optical zoom camera – even spot what they enter on the screen from across the room.
However, password masking is not a 100% security measure but anyone working in security promising you a 100% security is nobody you should trust anyways.
I do agree though that password masking can be very annoying on a mobile device, as is entering any form (my favourite bugbear is Opera Mini Uppercasing the first word I enter in any text field – no this is my user name, not a sentence).
As I am changing my passwords every few weeks I do get confused from time to time, too, which is why I have written myself a GreaseMonkey script that adds a link to any password field that allows me to toggle its display:
This, in my book, should be a standard feature of browsers (or a convention we should start to follow when we design forms) – not showing sensitive information as readable text on a screen just because we don’t think anyone would ever watch us.
Let’s also not forget that browsers deal with an input field with the type of password differently than with one that is text. For starters browsers do not collect previously entered information and offer them as options to autofill the field – something that would be terribly dangerous for passwords.
Tags: fields, masking, nielsen, passwords, security, usability
June 26th, 2009 at 10:50 am
Twitter Comment
RT @codepo8: In answer to Jakob Nielsen’s password masking post – how about making showing an option (GM script included):[link to post]
– Posted using Chat Catcher
June 26th, 2009 at 10:51 am
Twitter Comment
RT @codepo8 In answer to Jakob Nielsen’s password masking post – how about making showing an option (GM script included): [link to post]
– Posted using Chat Catcher
June 26th, 2009 at 10:54 am
Fully agree with you.
The option to show or not show the password should be something available on all browsers.
If not, it would be good if it became standard practise on web sites.
It’s actually mentioned at the end of the article on useit.com.
June 26th, 2009 at 10:55 am
Nielsen really talks out of his ass! :) Has he every tried watching someone type in their password? It’s really hard!
Quite a few mobile devices I’ve used show you the letter you’ve just typed very briefly then it hides, windows mobile does this and the iPhone is similar.
Nice script though and would be a great accessibility add on to a browser, a simple keyboard shortcut to toggle would be good. Also you’d want it to still not store it for autofill even if you make it readable, an extra feature for your script would be to catch the forms submit and set all fields back to password so they don’t get treated any differently, such as stopping the browser from offering to securely store it.
June 26th, 2009 at 10:57 am
My first reaction about Nielsen’s suggestion was: “this will be fun when Nielsen has to present a live app on a beamer and the whole audience will know his password then”. I had the same idea about leaving masking untouched and offering an option to unmask it on demand. Then I went back to the article and found Nielsen is suggesting this (although the other way round: mask on demand):
Quote: “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 agree, demasking on demand is the better solution. His main point, that masked passwords lead to ux frustration is true though. Failed Login statistics on sites I am admin on prove that.
June 26th, 2009 at 11:00 am
Hi Chris! I agree with you but there is another solution proposed by Apple on its iPhone. When tappe his password it is clear in the last letter tappa for 1 second and then it automatically hides. I found this solution interesting.
Bye ;)
June 26th, 2009 at 11:04 am
Twitter Comment
In answer to Jakob Nielsen’s password masking post – how about making showing an option (GM script included):[link to post]
– Posted using Chat Catcher
June 26th, 2009 at 11:05 am
This is also what Jakob Nielsen suggested, to remedy internet cafe security troubles and hotel lobbies. Smart script, though. Simple and elegant.
June 26th, 2009 at 11:09 am
The GreaseMonkey script you’ve implemented is actually very similar to what Jakob Nielsen suggested in the second part of his article, though it’s opt-in instead of being opt-out:
“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.”
You do however raise a very good point about the difference between text and password fields, especially regarding auto-completion.
June 26th, 2009 at 11:19 am
If we were to take Jacob Nielsens advice today, and change input type=”password” to type=”text” UA:s would not store the credentials. All password managers would need to be rewritten. Bad usability!
June 26th, 2009 at 11:19 am
Twitter Comment
“makes me wonder when was the last time that Mr.Nielsen left his house to communicate with the real world.” Indooring [link to post]
– Posted using Chat Catcher
June 26th, 2009 at 11:30 am
I’ve updated the script with my own suggestion: http://ts0.com/password_shower.user.js
June 26th, 2009 at 12:10 pm
Twitter Comment
@codepo8 an edit to put the fields back on submit and maintain normal functionality: http://ts0.com/password_shower.user.js
– Posted using Chat Catcher
June 26th, 2009 at 12:11 pm
Twitter Comment
@codepo8 thats a nice idea, I agree that Nielsen has it totally wrong this time. Is the way iPhone’s handle passwords a happy medium?
– Posted using Chat Catcher
June 26th, 2009 at 2:43 pm
That’s a nice script. When I’ve tried to do exactly this in the past, I thought I hit up against the browser not allowing me to change the type attribute of an input dynamically. Perhaps it was all a dream.
June 26th, 2009 at 3:57 pm
One of the most PITA experiences I’ve endured was getting my daughter’s iPod Touch onto our wireless system. The iPod has no paste capability, and has only a software keyboard, and our WPA password is 63 random characters. I learned that day that much of my ability to distinguish similar characters is contextual, and ceases to function when reading random text. Just to make the experience really fun, Apple threw in a ‘feature’: the entry dialog times out. I would have killed for the option to see what I was typing, and not just for an instant.
Let me suggest that taking options away from the user is rarely good usability design. Please allow me to decide whether I want to see what I’m typing. I know better than anyone what it is I want.
June 26th, 2009 at 5:32 pm
Twitter Comment
Oui car nous sommes souvent seul devant l’écran RT @DarklgWeb:On password fields masking and Jakob Nielsen [link to post]
– Posted using Chat Catcher
June 26th, 2009 at 6:03 pm
Twitter Comment
Shared on GReader: On password fields masking and Jakob Nielsen: Jakob Nielsen just posted on .. [link to post]
– Posted using Chat Catcher
June 26th, 2009 at 6:51 pm
@DavidCabana agreed. That’s what my solution empowers you to do. The timeout is a dangerous assumption, not everybody is a fast typer.
June 26th, 2009 at 7:02 pm
Twitter Comment
Reading: On password fields masking and Jakob Nielsen: Jakob Nielsen just posted on alertbox that we sho.. [link to post]
– Posted using Chat Catcher
June 28th, 2009 at 9:18 am
I’m glad J. Nielsen finally addressed the usability problems encountered by criminals: it’s way too hard for them to guess what is being typed on the keyboard by honest people.
Does he plan a(n) usability study with real ones?
June 28th, 2009 at 11:05 am
I love the idea of the “show/hide password” button!
June 29th, 2009 at 2:09 pm
He is not thinking about situations outside home or office. But show/hide button could be a good option.
July 1st, 2009 at 8:45 am
I was working on a similar userscript: http://userscripts.org/scripts/show/52442 This script places the link inside the password field instead of next to it.
I have also created two solutions that work in all major browsers: a javascript function that you can use on your own site to add this kind of toggling functionality to your forms, and a bookmarklet to use everywhere else. http://jaron.nl/blog/2009/how-to-unhide-passwords-on-your-site-and-everywhere-else/
July 2nd, 2009 at 5:41 am
Twitter Comment
Reading: “Wait till I come! » Blog Archive » On password fields masking and Jakob Nielsen” ( [link to post] )
– Posted using Chat Catcher
July 2nd, 2009 at 5:34 pm
Twitter Comment
@ryancarson I’m going to have to agree with @codepo8 on this one – it’s a terrible idea. [link to post]
– Posted using Chat Catcher
July 2nd, 2009 at 6:02 pm
Twitter Comment
@codepo8 once again delivers: [link to post] I echo the sentiment regarding native browsers responsibility
– Posted using Chat Catcher
July 2nd, 2009 at 6:03 pm
Twitter Comment
A good reply to Jacob Neilson’s password masking post by @codepo8: [link to post]
– Posted using Chat Catcher
July 2nd, 2009 at 6:04 pm
Twitter Comment
RT: @rakesh314: A good reply to Jacob Neilson’s password masking post by @codepo8: [link to post]
– Posted using Chat Catcher
July 3rd, 2009 at 3:48 pm
Christian,
What Jakob didn’t mention or consider is that there are lots of place where you absolutely are surrounded.
Such as at school. When I was at school (just last year) it seemed to be a common thing for kids to try and look at others’ passwords. Even if it’s just as a joke in a kind of “Haha I know your password” type way!
So the idea of unmasking passwords on computers is ridiculous. I would choose not to use a website if the password was not hidden.
The script (or general idea of having a hide/unhide option) is great, until you are hit with the exact scenario above where most schools/offices use IE6 as opposed to Firefox.
July 4th, 2009 at 1:06 am
http://andrewchee.tumblr.com/post/129688047/in-response-to-jakob-nielsens-stop-password-masking
July 23rd, 2009 at 9:14 am
Disagreeing with Jakob Nielsen on masking passwords and a simple cross-browser solution to reveal passwords