Usability researcher Jakob Nielsen’s recent column advocates a fundamental change to password field design on the web. He believes that the time has come “to show most passwords in clear text as users type them,” abandoning the traditional approach that displays a series of asterisks or bullets in place of the actual password.
Nielsen’s controversial proposal demonstrates the principle that most design decisions require trade-offs. User goals and business objectives do not always intersect. Security, usability, and aesthetic concerns often compete. We must set priorities and balance these interests to achieve the best results in each situation.
Security issues are particularly difficult to deal with because they’re an annoyance. We just want to let people get at the great tool we’ve created, but instead we have to build barriers between the user and the application. Users must prove their identities. We can’t trust any data they provide unless it’s been thoroughly sanitized.
Unfortunately, this is reality. A great deal of web traffic really is malicious, and sensitive data gets stolen. Typically, we ask users to supply a username (often an e-mail address) along with a password to sign in to an application. The username identifies the person, while the password proves that the person submitting the username is indeed the one who created the account. That’s the theory, based on two assumptions:
- A password will never be visible outside the mind of the person who created it.
- Both the username and password can be recalled from memory when needed.
This approach places a significant cognitive burden on people who use websites that require authentication. In general, we get by remarkably well, but it’s easy to see the weaknesses in the system. Passwords that are easy to remember are also easy to guess. When people are forced to choose strong passwords, they’re more likely to either write them down or forget them. The usual response is a password reset mechanism, which naturally undermines the strength of the entire system. It doesn’t matter that my password is encrypted with the strongest ciphers known to man when it can simply be reset by anyone who knows which high school I attended.
This is one of the reasons that Nielsen suggests abandoning password masking. People get frustrated and often reset passwords that they haven’t actually forgotten simply because they’ve mistyped. Providing clear feedback with unobscured letters will reduce errors, improve the user experience, and lessen the need for insecure alternatives.
However, making such a sweeping change to a fundamental user interaction could present serious problems. Consider some contexts in which a password might need to be entered in front of a large group of people, such as while using a conference room projector. And many years of web experience have set user expectations on how form elements should work. People understood that password masking was invented for their security. Failing to meet that expectation might undermine confidence, and we cannot afford to lose our users’ trust.
Is there a middle path—a way to provide feedback and reduce password errors that doesn’t sacrifice the user experience? At least two design patterns address this issue in offline applications, and with a little JavaScript, we can bring them to the web.
Now you see it, now you don’t#section2
The simplest solution is to mask the password by default while giving users a way to switch the field to clear text. Nielsen even mentions this in passing. This approach allows the person to confirm that the password was entered correctly, but it also places control firmly in the user’s grasp. Such toggle controls are often seen on WiFi preference panels, but they’re rarely implemented elsewhere. (Note: at least one blog has advocated a similar technique while this article was in production.)
It should be simple to write a control that switches the type attribute of an HTML input element between password and text. Unfortunately, it’s not. Internet Explorer does not allow this particular attribute to be set by JavaScript, so we have to be slightly more creative. The following two functions should do the trick:
(Line wraps marked » —Ed.)
window.onload = function() {
if(document.getElementsByTagName) {
var inputs = document.getElementsByTagName('input');
for(var i in inputs) {
var input = inputs[ i ];
if(input.type == 'password') {
toggle_control = document.createElement('label');
toggle_control.innerHTML = "<input type=\"checkbox\ »
" "+ "onclick=\"toggle_password('"+ input.id+"',this »
.checked) \" />"+" Show password";
input.parentNode.insertBefore(toggle_control, input »
.nextSibling);
}
}
}
}
function toggle_password(element_id, show_text) {
if(document.getElementById) {
var password_input = document.getElementById(element_id);
var new_input = document.createElement('input');
with(new_input) {
id = password_input.id;
name = password_input.name;
value = password_input.value;
size = password_input.size;
className = password_input.className;
type = show_text ? 'text' : 'password';
}
password_input.parentNode.replaceChild(new_input, »
password_input);
}
}The first function scans the document for all input elements and collects those of the password type. Note that this code is only intended to demonstrate the concept, and the process might be improved by using a JavaScript framework such as Prototype.
After each input, the function inserts a labeled checkbox to toggle the field between masked and clear text. The second function controls the toggle behavior itself. When the user clicks the toggle control, the function creates a new input and swaps it for the existing one, juggling the value and other properties between them.
An alternative approach is to create the text input only once and toggle the display property to show or hide the appropriate field. One drawback to this method, though, is that an element’s id must be unique. Since the parallel text input would have its own id, it wouldn’t inherit any CSS rules that referenced the original element by ID.
Take a look at example one to see it in action. This solution is easy to implement, and it follows the principle of progressive enhancement: In the absence of JavaScript, password fields will retain their usual behavior. The toggle control empowers the user with a choice as to whether to show or hide a password in a particular circumstance. The main drawback is that it could still undermine a user’s concept of the password field as a “black box.” We’re so completely accustomed to thinking of our passwords as a secret that merely offering the option to display it in clear text could be unsettling.
A second alternative#section3
Typing errors are especially common on touchscreen devices such as the iPhone, where fingers can’t locate the edges of keys by feel. Anticipating that password inputs without visual feedback would cause problems, Apple adopted an interesting approach. The last letter typed into the field remains visible for a couple of seconds before turning into a dot. This creates an opportunity to catch errors without showing the entire password at once.
We can reproduce this progressive masking behavior with HTML and JavaScript, although it will take a bit more code than the previous example. Consider the following:
window.onload = function() {
if(document.getElementsByTagName) {
var inputs = document.getElementsByTagName('input');
var password_inputs = Array();
for(var i in inputs) {
if(inputs[ i ].type == 'password') {
password_inputs.push(inputs[ i ]);
}
}
for(var i in password_inputs) {
var input = inputs[ i ];
var masking_element = document.createElement('input');
with(masking_element) {
style.position = 'absolute';
id = input.name + '_mask';
type = 'text';
size = input.size;
className = input.className;
}
masking_element.onfocus = function(){this.nextSibling »
.focus()};
input.parentNode.insertBefore(masking_element, input);
input.onchange = function() {
if(this.timer){
clearTimeout(this.timer);
}
var mask_character = "\u2022";
var last_character = this.value.charAt(this »
.value.length-1);
var masked_text = this.previousSibling.value;
var password_text = this.value;
if(masked_text.length < password_text.length) {
this.previousSibling.value = password_text.substr(0,
password_text.length-1).replace(/./g,
mask_character)+last_character;
} else {
this.previousSibling.value = password_text »
.replace(/./g,mask_character);
}
this.timer = setTimeout("with(document.getElement »
ById('"+masking_element.id+"')){value=value »
.replace(/./g,'"+mask_character+"')}",2000);
}
input.onkeyup = input.onchange;
input.onchange();
}
}
}This time, we create a second text input to sit directly on top of each password input (the caveat about CSS inheritance from the previous example applies). By manipulating its value as the original field changes, we can control what the user sees. Let’s break down each step of the script:
window.onload = function() {
if(document.getElementsByTagName) {
var inputs = document.getElementsByTagName('input');
var password_inputs = Array();
for(var i in inputs) {
if(inputs[ i ].type == 'password') {
password_inputs.push(inputs[ i ]);
}
}
for(var i in password_inputs) {
var input = inputs[ i ];
...
}
}
}Again, our first task scans the page for password inputs so that we can modify their behavior. However, there’s a critical difference between this function and the first example. In Internet Explorer, document.getElementsByTagName() doesn’t return a simple list of matching elements at the moment the script is run. Rather, it returns a reference to the collection of matching elements. If we create a new input element while looping over the results, we will increase the size of that collection on each pass, and the loop will continue indefinitely. This instantly crashes Internet Explorer (and not gracefully). So, instead, we need to copy the initial results of the function into an array and loop over that.
var masking_element = document.createElement('input');
with(masking_element) {
style.position = 'absolute';
id = input.name + '_mask';
type = 'text';
size = input.size;
className = input.className;
}
masking_element.onfocus = function(){this.nextSibling.focus()};
input.parentNode.insertBefore(masking_element, input);With the new input inserted directly before the existing one, setting its position to absolute should place it directly on top. This should work in most layouts, but there may be exceptions where additional CSS is required to position it correctly. Of course, now that we’re covering the input with another element, we also need to make sure that clicking on the mask activates the input. Adding an onfocus handler takes care of this. We have to assign this handler outside the with statement for it to function correctly in Firefox 2.
input.onchange = function() {
...
}
input.onkeyup = input.onchange;With the new element in place, we’ll build a function to display the text of the progressively masked password. We’ll need this text to respond to changes in the contents of the password field. Usually, this will mean that a user is typing on the keyboard, but that may not always be the case. Someone might paste text into the field using a context menu, for example. Attaching our code to both the change and keyup events should cover all the bases.
var mask_character = "\u2022";
var last_character = this.value.charAt(this.value.length-1);We can define any character we like to mask the passwords. Traditionally, most systems use asterisks or dots, so in this example we define the Unicode entity 2022, which is the bullet character. On the second line, we identify the last character of the current password value so that we can render it in clear text.
var masked_text = this.previousSibling.value;
var password_text = this.value;
if(masked_text.length < password_text.length) {
this.previousSibling.value = password_text.substr(0,
password_text.length-1).replace(/./g, »
mask_character)+last_character;
} else {
this.previousSibling.value = password_text.replace(/./g,
mask_character);
}Now we can take the value of the password field, replace every character except the last one with a bullet, and put that text into the field that we’re using as a mask. However, we should only do this while the person is typing forward. In other words, if the user presses the backspace key, we don’t want to reveal the previous character again. After it’s been hidden, it should stay hidden. So before performing the replacement, we first check to see if the password value is longer than the masked text. The replacement itself can be done using a simple regular expression. The expression /./ matches any character in the password field. Adding the letter g to the end, (/./g) means that it scans the entire string of text instead of stopping at the first match.
this.timer = setTimeout("with(document.getElementById('"+
masking_element.id+"')){value=value.replace(/./g,'"+
mask_character+"')}",2000);After a two-second delay, we want to mask the full password. However, our users probably won’t pause for two seconds after typing each letter. So we only want the behavior to take effect when the password field hasn’t changed at all for that length of time. Every time we call the setTimeout function in JavaScript, it returns an ID that we can use to reference that particular timer.
if(this.timer){
clearTimeout(this.timer);
}By storing the timer ID in a variable and adding the above code at the beginning of our function, we can cancel the countdown as long as we observe that the field is still changing.
input.onchange();Our last step is to run the function we just defined. This ensures that the mask will show the correct text if the password field was pre-filled before the page was loaded.
To see the full script in action, take a look at example two. It’s been tested in Internet Explorer 6-8, Firefox, Safari, and Chrome. Again, in the absence of JavaScript, this technique will degrade well—password fields will simply function normally.
Proceed with caution#section4
When dealing with such a fundamental area of the web experience, we need to be careful because we’re dealing with deeply conditioned expectations. The username/password method of securing web applications isn’t perfect, but there are few good alternatives and it’s become the standard approach. We can best address the usability concerns of password fields by testing incremental changes like these to extend default behavior—without compromising the basic experience and losing the trust of our users.
What’s the connection between people having to remember passwords, password resets, and cleartext passwords? Surely there’s a considerable difference between typing in a password while someone is ogling your screen and having someone hack into your email account, reset your password, receive the new password in your email account, and impersonate you?
I don’t buy it. I hate seeing my passwords in cleartext, it means I have to look around for suspicious people before logging in/signing up for a website.
Also, anyone who knows what highschool I went to can reset my password? Yes, but that reset password is sent to your email address, and if they have that you’ve already lost. Also, pick a better security question. “What high school did I go to” is known by many, but “What was the date of birth of the first girl I slept with” or “What odd medical condition does my father have” are a little more secure and still easy to remember.
A little unrelated, but a pet peeve of mine is when I get an email that says “your password is yaddayadda” and I just think “so you’re not encrypting my password?” but yeah, anyways that’s unrelated.
Back on topic, passwords are “a significant cognitive burden”? So what? What about remembering my NI number, my passport number, my ZA ID number, my driving license number, my street address, my telephone number and my cellphone number? Just deal. I think web designers/developers should do their part and make the site as secure as possible, everything else is the users responsibility.
Andrew
These debates often make me laugh. They often demonstrate a clear lack of understanding on the part of the author.
Ok, this article is meant to tackle the UX part of authentication, the fact we should be using more complex passphrases that are prone to mistyping, and how to reduce the apparent barrier to entry of a site (without compromising security).
The presented technique has a simple but significant flaw in that it does reduce the security of the site. Text Input fields can be copy/pasted from, Password fields can only be pasted to (not copied). If you use a technique that replaces the password field with a text input, it opens the possibility of a browser addon stealing the password. Ok, you might accept that a keylogger has the same capability.
Banking systems often get around the problem of mistyping by reducing the number of letters extracted from the password that are required for input (i.e. enter the first, six and last letters), which are randomised on each input and still concealed from view. However, this means that the server requires to store the password in the plain (or at least with some common decryption key), and means if the server is compromised all passwords are revealed. I never recommend the storage of the original password on a server – a hash should be stored which cannot be simply reverse engineered, but can be compared in its entirity to a hash generated on user input (so the hash itself would not succeed if used as user input). If the server is compromised, the hash is of limited value.
A bigger question in my mind lies in the definition of the user ID (email, nickname etc), and the definition of a strong password. I see so many sites these days implementing password strength tests whilst still majorly compromising the users choice of password content. e.g. they might insist on a mixture of letters and digits, but prevent spaces or overall password length, which means I can’t use an easy to remember phrase e.g. ‘a list apart is the 1st site i visit each day’ might be a very useful password which I can vary on each site I visit and still meets the requirements of a strong password. Instead the geeks out there seem to suggest I should use arcane passwords such as ‘B%^Dg6@’ unique to every site – how on earth are we supposed to remember those without writing them down or at least using a password manager.
The ID element is also more complex than meets the eye. My email address is unique to me (although many people share an email address amongst family members), but in the event that I loose access to my email address (a common occurrence) I cannot use most password reset/reminder systems as they require access to the recorded account address. A nickname may not be unique to me – how often has your preferred nickname already been taken by your favourite website – how often have you lost access because you can’t remember which nickname you used?
I’d love to see an ALA article written by a respected security expert that provides some clear guidance to UX designers and site developers on what is considered best practice, rather than piecemeal articles that only serve to weaken the security of websites when presented without the caveats.
Having just posted above, and needing to signup in to ALA for what is my first post, I can’t believe there is no apparent way for me to modify my own registration details! No link anywhere! No confirmation email from ALA on my new registration, with details of how to unsubscribe.
What gives!
It’s my opinion that some things are better left to browsers. Ever filled out a form that was poorly done in flash? It’s obnoxious because it doesn’t behave like every other form element the browser renders.
I don’t mind changing some aesthetics of the form to match a site, but this feels like one of those items that is better left to the browser (like what if we could markup a scroll bar on the left of the screen).
HTML provides us with a password input to use and leaves it up to the browser to accomplish its function, “The user agent should obscure the value so that people other than the user cannot see it.” (W3C HTML5)
how would this affect the browser’s ability to remember the password?
I don’t believe that we should mess around with standard controls.
A centralized authentication service might one day be sufficient to remove password identification requirements on third party sites completely – maybe google can do this…but the tradeoff would be that every site that you visit, after you’ve signed in, would know you, and your information…
I like this article, and love that in a Mac you can see wireless connections’ passwords whereas in Windows you can’t. Letting the user choose seems like the best of both worlds. In the programming aspect of it, I don’t really know much about it, but would JQuery also do the trick maybe with less code?
Excellent article.
This area of usability is really difficult to judge. I think in most cases it would make the user feel more vulnerable – I know that it would make myself and many of my friends, colleagues and family feel that way.
@rosaiani: There is an option on Windows Vista that allows you to see the password.
I liked the article myself, even if I probably won’t end up implementing it. If I were to choose one of the two methods mentioned (Using plain-text passwords doesn’t count as a real option) I would probably choose the first, the ability to toggle between the two. Your implementation was rather nice on that one.
The second technique, however, posed some problems for me. First, it might be my browser alone, or a result of the attached events, but the cursor showing my typing position didn’t work correctly (as in, I couldn’t ever see it :P). Also, with the way that implementation was written, it’s impossible to delete and replace the first (or middle) letter of the password. Deleting the first bullet in the text field will remove the last letter from the password field. And while I would assume that users do not often do this, it would still break were they to try.
In 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. We can’t find the status of capslock specifically, but we can mostly determine one way or the other. though I don’t have time currently to write up an example in Javascript, I can give you some (very)pseudo code:
On keypress (in the password field):
A. Check to see if the letter presses is a capitol letter.
B. Check to see if the shift key was held for this event.
Now, if it was a capitol without Shift, then caps lock is probably on.
Also, if it was NOT capitol but shift WAS held, caps lock is probably on.
If caps lock is probably on, display a warning. If not, clear the warning (if it exists).
Well, I guess that’s all for now. I can write up an example function and post it here later if there’s any interest.
But overall, thanks for the great article Lyle.
Despite the obvious issues and concerns raised already in these discussions, it’s clear that there will be support for these techniques – at least in some arenas. Apple’s implementation on the iPhone is clear evidence of this. I, for one, am avidly in favour of improvements that make it easier for the user to enter their details correctly.
For UX designers set on implementing these techniques, the emphasis should lie on minimising the differences between expectation and delivery. Users will expect their ‘improved’ password field to still respond to human interface (typing, backspacing, pasting, selecting, etc.) in the same way the old fields did, but if they don’t it could lead to serious issues of distrust.
In testing the Progressive Masking technique (Firefox, Chrome, Safari) it becomes evident that the overlay field plays havoc on the user’s ability to select characters in the same way the password field allows. Consider a user who enters their password incorrectly, is notified by the overlay, and uses Shift + ← to highlight and delete the incorrect character. The user gets no indication of the password being highlighted, and thus becomes suspicious of the integrity of the password field, and the environment in which it resides.
Similarly, when the user attempts to highlight with the text selector cursor, the user either gets no feedback as to what is being selected (Chrome, Safari), or the masked layer is selected but cannot be manipulated (Firefox).
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.
I know there was some controversy when Nielson first mentioned this. Then, as now, the only real argument I’ve heard that makes any sense in a user experience setting is the added confusion by discarding a known consistency. Otherwise, I’ve heard no argument that justifies the extra development time or potential for conflict that the “solutions” offered here (and elsewhere).
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).
Or, maybe the issue is pretty non-existant, and we’re worrying over nothing. In both cases, these half-measures only muddy the situation. Instead of one known interface that does or doesn’t work, we have 3 (or more) interfaces, none of which really fix the core issue.
Better yet, get rid of passwords altogether. The response from users of my password-less service “wasitup.com”:http://wasitup.com has been great.
I noticed the suggested solution, whereby the user has a checkbox which would allow them to switch between a plain-text and password type field for their password was, well, to be brutal, pointlessly more complex than it needed to be.
Rather than creating a new, cloned, text field to be able to switch to and from instead of the password field, why not just have the javascript action, performed on a user click, change the “type” attribute to “password” if it was “text” or to “text” if it were “password”? Creating a second field, really, seems to provide no added functionality from what I can see.
I am happy to be proven wrong, though.
Thanks for the feedback, everyone.
@Andaith: The point is that having any automated password reset mechanism undermines the security of the entire system. An attacker is able to modify the password without having knowledge of it. The relationship of Web application authentication to email accounts is a separate discussion, though an interesting one.
@dmeehan: The contents of a password field can be easily read by JavaScript (otherwise the techniques demonstrated wouldn’t work). Masking protects the password from eyeballs and nothing else. Except to the extent that the password can be seen by an observer, these techniques do not introduce any vulnerability that doesn’t already exist.
@AdriaanNel: Both techniques should work as expected with pre-filled password fields. This is important not just for browser-level features, but in the case of validation where a user is redirected back to a form to supply additional information.
@rosaiani: Yes, a framework could make this easier, and the article mentions that. But JQuery is just one option (everybody has their favorite), so I wanted to demonstrate the concept without marrying it to a particular framework.
@Chibu and @juanojeda: The point about editing an arbitrary character in the progressive masking technique is a good one. The function could probably be made more sophisticated to handle this situation. However, this does seem to be a pretty unlikely behavior.
@uggedal: Nice site. I like the interface, and the passwordless system seems like it would work well there. However, this is definitely not always the case. For instance, I work for a robotics company and our service tracking system (which I develop) is a web application accessible (by necessity) to the internet. This system contains sensitive company data. Therefore, it is really not possible to not use passwords. Even though this security measure is by far not foolproof (a lost laptop with a saved password for instance), it is a necessary step to attempt to preserve the integrity of the system. Though, don’t get me wrong, as noted, I think in your case you are absolutely correct, passwords for the service you’ve linked would be more than necessary. Worst case scenario, you get receive an incorrect email, or do not receive an email at all.
So, I would therefore say that the level of security–passwords, ease of reset, etc–should be based on the sensitivity of information contained. Thanks for the link. I’ll have to keep that in mind next time I’m working on a project with non-sensitive information.
@Lucanos: The technique you described doesn’t work in Internet Explorer. IE doesn’t let JavaScript set the type attribute of an input element.
I think your post could be simplified – you’re outlining iPhone password entry behaviour for desktop and laptop. The reason it works well for iPhone is the on screen keypad small and therefore is more prone to mistakes. Also, the last character feedback is useful because the distance between the keypad and input is small enough for the user to see both.
The majority of people cannot touch type. I’ve observed laptop/desktop users whilst typing and they tend to concentrate on the keyboard until they have finished. So they won’t see the last character feedback.
The long term solution would be to remove passwords entirely by identifying an individual using another method, biometrics perhaps. The medium term solution is to make open id the de facto standard for all services. There by only having to remember one strong password.
The solution I recommend people use today is software like 1Password. It keeps an encrypted database of all your logins, which as the name suggests can be recalled by using one password. I’ve got over 100 logins in my database, which frees up my human memory for more important things.
Small note on your demo’s implementation. I know it’s a proof of concept but your code removes the i-beam!
I think your post could be simplified – you’re outlining iPhone password entry behaviour for desktop and laptop. The reason it works well for iPhone is the on screen keypad small and therefore is more prone to mistakes. Also, the last character feedback is useful because the distance between the keypad and input is small enough for the user to see both.
The majority of people cannot touch type. I’ve observed laptop/desktop users whilst typing and they tend to concentrate on the keyboard until they have finished. So they won’t see the last character feedback.
The long term solution would be to remove passwords entirely by identifying an individual using another method, biometrics perhaps. The medium term solution is to make open id the de facto standard for all services. There by only having to remember one strong password.
The solution I recommend people use today is software like 1Password. It keeps an encrypted database of all your logins, which as the name suggests can be recalled by using one password. I’ve got over 100 logins in my database, which frees up my human memory for more important things.
Small note on your demo’s implementation. I know it’s a proof of concept but your code removes the i-beam!
I’ve been reading “The design of everyday things” recently and the author talks about UX and good design but makes the caveat that things like “security” may need to go against good UX design.
An example he used is of a school door with a “bar lock” at the very top of the door to prevent kids from leaving early. Its a security feature, but its clearly not “usable”. It is good design, but bad UX. What would happen in a fire?
The big problem with passwords is that it’s “knowledge in the head”. And your absolutely right. Designers think that by putting a stared-out password box, that their website is secured. But our minds can only remember so much random stuff.
How many passwords do you have? Think about it. You can’t possibly remember more than 5 or 6. So you have to either write them down, make them all ultra simple, or make the vast majority of them the same password. How many people have the same password for their bank accounts that they have for their yahoo mail?? How secure it that? Forcing people to pick “strong passwords” that resist cryptographic attacks just forces people to write them all down (maybe even email them to themselves).
The iPhone’s solution to visible passwords works well on a small platform with a touch screen, but I’m not sure its a good solution on a 24-inch display with a keyboard. I like the idea of a toggle for the password box to show the visible cleartext, but I feel there’s something more that’s needed.
Can you provide a key to a website that doesn’t require you to memorize a long random string? Not a cookie, but something that you can use when you want to? I think it’s a better mapping to the problem.
Loved the article. Great work making us think. 😉
I’m surprised no one has mentioned something like Chroma-Hash:
http://mattt.github.com/Chroma-Hash/
Knowing the colors is useless for shoulder surfers, but accomplishes the goal of the user knowing if the password was typed in correctly.
The only security that the password field gives is from someone peeping ‘over the shoulder’. Why not leave the option to the user? If he/she is in the middle of the crowd, hide it, else show it.
This was discussed in an article in the page below. The password widget has other ‘good to have’ password features too.
“A rich password widget”:http://www.html-form-guide.com/blog/web-form-widget/54/web-form-password-widget/
Further, the ‘Show’ link in the widget doesn’t add any complexity to the widget.
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.
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.
I like both options but think I would go with option 2. The user wont have to do anything different.
@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.
@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.
@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.
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.
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.
Great article!
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).
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.
Those are good scripts, but there’s a little bug in the second alternative script.
In the part that says:
It should say:
The original will break when there are input elements other than password.
Ups! (it appears that HTML doesn’t render as source code as said in the comments form)
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 ).
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
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 == “”)
{
@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:
bq. 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.
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.
function togglePassword(elementId, showText) {
var newPasswordField = $(elementId).clone(true);
$(newPasswordField).attr(‘type’ , showText ? ‘text’ : ‘password’);
$(elementId).replaceWith(newPasswordField);
}