Password Usability & Typability

I have a lot of sites that need passwords. I've tried a number of different methods for making secure but easy to remember and type passwords.

One thing that bothered me is that it's a lot different typing when you only see a bunch of ******'s show up. So I've set up a previewing page you can save to your computer and use to test how easy it is to type a password.

I strongly recommend you save the page to your hard drive before you use it. I ended up running a usability test on myself: I managed to mistype my new password twice, so now I've modified the page so that you entered the prospective new password twice.

There is a tension between usability and security. Nowhere is that more obvious than with passwords. System administrators want their users to use passwords like "WeRQ#$^zfbr" and users want to use "bob". I believe it's possible to find a reasonable compromise between both.

Here is my list of DOs and DON'TS to picking a password:

  • DO NOT use an entire real word, English or foreign, for a password. Keep in mind some systems will not even allow part of the password to be a real word.
  • DO NOT use login names, birthdays, social security numbers, names, favorite fantasy characters: pretty much anything that is easily guessable.
  • DO NOT use capital letters in the middle of a word. This is hard to type accurately.
  • DO NOT use two letters repeated. It's easy to type two "tt"s wrong. Avoid repeating letters at all, in fact. "enterer" is a pain to type accurately.
  • DO NOT use spaces, and don't start with a number; some systems cannot handle them.
  • DO NOT use the common recommendation of taking a phrase like "I went to the store and brought some bread." and converting it to "Iwttsabsb" This will tend to produce hard to type passwords.
  • DO NOT use any part of an old password. It's a bad idea, and some systems will not allow it.
  • DO NOT change your passwords right before a weekend or before you go on vacation!
  • DO use a number, a capital letter, or a symbol like "%". Some systems require one, or even two of each.
  • DO make up words that are easy to say and type. A good starting place is fantasy name generators [Third link removed because it crashes Mozilla/Firefox every time with some COM/ASP junk --03/28/2004], but always change some of the letters. If you make the word too easy, you may be hitting a foreign word by accident: I recommend always putting at least one number, letter, or capital in somewhere.
  • DO use a different, "throwaway" password for sites (often newspaper ones) like the New York Times that need it. This is an easy password you can reuse for sites where the worst that can happen is that someone pretends to be you reading the New York Times.

A more subtle point for people who type faster: keep in mind there are certain typos that happen because the wrong pattern is faster. This is one reason "teh" happens: the "t" and "e" are on the same row, but the "h" is on the right hand. Try to pick patterns that work with rather than against this tendency. (Anyone suggesting "typewriter" as a password will be smacked.) I generally find letters flowing from left to right more conducive. Some bottom row letters can give me fits at times.

Finally, have fun. A password that means something to you will be easier to remember.

Posted by Chad Lundgren on Saturday, October 26, 2002 (Link)

Comments

Posted by Vincent Monday, October 28, 2002 at 08:53 PM

or use a pass word manger like netscape 7.0 has bro :-)

Posted by dan Wednesday, October 30, 2002 at 08:38 AM

So what's to prevent the casual onlooker from viewing an entered password?

I believe the password input stars were orginally added to help prevent "over-the-shoulder" password snatching.

This password usability idea makes the assumption that the user in question is always alone when entering passwords.

Posted by Chad Lundgren Wednesday, October 30, 2002 at 09:32 AM

There's nothing to prevent casual observers from seeing the password. This is probably why I say, on the preview page itself, "Do not use this page where someone might be looking over your shoulder. I am showing you the password you typed so you can see how well you typed it."

The theory being that assuming someone can get a little privacy, they may be able to find a better password. I would think shoulder surfing what someone types even when the password is hidden with *****'s is easier when someone picks a silly password like "robert1" for username "robert". Since password change doesn't happen nearly as often as login, this seems like a net gain to me.

Posted by Chad Lundgren Wednesday, October 30, 2002 at 10:23 AM

Since Movable Type links commenters names to web addresses if supplied instead of to their email addresses, you didn't see Dan's email address, "email@canbfaked.org". I did see it in the comment notification email I got. So why do I require an email address?

Usability is sometimes about constraints. There are two kinds of people: those who know email addresses on web logs can be faked, and those who don't. When this majority sees that an email address is required, they assume the "computer knows" if they aren't putting in a real email address.

I don't mind fake email addresses. In fact, I appreciate it when people go to the trouble to make something up. It's worth mentioning that Movable Type puts in anti-spam protection for email addresses.

Posted by dan Thursday, October 31, 2002 at 02:03 PM

*ahem* Sorry didn't see the disclaimer....you should know users don't read *wink wink nudge nudge*

I still fail to see the usefulness of this. If you want to users to their see what they're typing...just use regular inputs. If your not concerned with shoulder surfing then whats the point of using password inputs? Better yet...whats the point of using password inputs with javascript goofyness to display what the users typing anyway? Food for thought.

As for the fake e-mail address...eh...it's a default of mine (anti-spam habit...and even MT isn't spamproof). I figure if someone wants to e-mail me they can do so via my site. =)

Posted by Chad Lundgren Thursday, October 31, 2002 at 02:42 PM

I'm simulating password change forms which display ****'s when you type. The lack of *immediate* feedback on what characters you're typing makes it harder. A regular input field gives *immediate* feedback on which characters you're typing, which defeats the purpose.

My fake form gives you feedback at the same time real forms say "You screwed up" but my form shows you *how* you screwed up--or not.

In a related vein, Lotus Notes makes password entering even more irritating:

http://www.iarchitect.com/lotus.htm#LOTUS12

Posted by dan Thursday, October 31, 2002 at 04:01 PM

"A regular input field gives *immediate* feedback on which characters you're typing, which defeats the purpose."

And what purpose is that? Feedback? Wouldn't you want immediate feedback?

There is absolutely no point to using password inputs if you're just going show the user what they typed anyway...regardless of whether it's immediate or 5 hours from now...you're still REPEATING what they type. Why not skip all the hoopla and let them type in regular inputs...THAT is the correct usable solution. Like I said...there is absolutely no viable reason for doing this.

Posted by Chad Lundgren Thursday, October 31, 2002 at 08:10 PM

You may want to be a bit less strident. I dislike capital letters, it's the equivalent of SHOUTING. (To me, asterisks are a poor man's italics).

Have you conducted usability tests? I have. There was one where, despite my best efforts, the employee's boss showed up, and the employee, to my eyes, mistyped the password twice, and then got it right the third time. I'm reasonably sure the boss saw the employee was mistyping it too.

Said employee was *convinced* she was typing it right the whole time: she knew it was the first release and it might be buggy. If she were able to use this form, she would believe she'd typed it wrong when it was echoed back. Seeing is believing.

I never said my goal was to set up my page in the easiest way for people to just *see* their password, which seems to be your argument. If all they wanted was to just *see* their password, they could just bust out a pen, or type in their favorite word processor. Why would I want to reinvent the wheel?

The *actual* goal, the reason Javascript was needed, was to let people discover how easy it is to *type* a "usable" but still secure password. If it just showed it on the page as you typed, it would not be a rigorous enough "usability test" of the password. It would not reflect reality, as usability tests strive to.

Your argument oversimplifies usability. Usability is not just about making things easy, it's also about constraints. I'm matching the real world constraints of password change forms.

By matching those constraints, I'm helping people see how they are messing up prospective passwords so they can avoid the ongoing pain of a bad password. I'm helping them reject bad passwords. The way I you end up in the first password field, you can keep on typing as many times as you want. It's rarely on the first try that I realize how bad a password is. It's the on 4th or the 10th.

I was stuck with a bad password of my own devising for months and hated it. I often had to try 2, 3, or even 4 times. The few extra minutes spent picking a good password pay off over time.

Think of it as a game, man. See how fast you can type the same password twice, ten times in a row. I should go add timing code and set up a top ten list for fastest typists in the west.

Posted by dan Thursday, October 31, 2002 at 11:47 PM

I'm a Usability Analyst for a very well known worldwide brand. I also have over 17 years experience in HCI and design to boot...I think I've done a few "test" in my time.

I understand completely your point...I'm afraid you don't follow mine.

I'm asking why is it necessary to use password inputs? All your doing is showing what the user typed. Acknowledge that and we're half way there.
Your scope is to limit typos during password entry...which by way of your testing has concluded that the starred out password fields aren't providing clear enough feedback. So you've devised a javascript to repeat what the users type after completing the password fields.

Groovy...but it's overkill. By changing the password inputs to standard input fields the users are getting instant feedback on their typing...thus are able to change any mistypes on the fly. Combine that with client side validation and voila...no more password typo problems.

And yes, I'm also aware that caps are consider shouting...but can also be used for emphasis...similar to *this* also being used to represent third voice.

Posted by Chad Lundgren Friday, November 1, 2002 at 01:29 AM

I'm going to assume the multiple comments on your part I deleted from this entry and the other were accidental. I have no tolerance for blog spam.

You say: "All your doing is showing what the user typed. Acknowledge that and we're half way there."

What? Most of the previous comment was emphasizing that I was showing what the user typed. By saying "Acknowledge" you imply I'm trying to deny it when I emphasized it.

Dan, your solution would help people get better at typing passwords into fields that actually display the password. This is rarely done. Your solution solves a rare problem.

You also seem to be assuming this is problem that can be solved once. It can't be: the real world is too heterogeneous. I wrote a tool, not a prototype, one that is applicable to most password change forms.

This tool can be used *today* to help create passwords that are easy to type when asterisks are used, as they are on an online banking site, or a Yahoo email account. Any site with trivial security requirements can show passwords, but most things need actual security.

Typing into a password field, with only ****'s to show for your efforts, is so different from just typing into a regular field that doing one does not help the other. This is certainly the case for me, and has been the case for others I've observed. How broadly this is applicable I have not tested.

We may have to have to agree to disagree. Either that, or talk some neutral third party into running a test. One of the first things that attracted to me to usability was its ability to end otherwise endless debates with actual data.

Posted by dan Friday, November 1, 2002 at 08:43 AM

hmm...I apologize for the multiple entries...I received server errors on submit. *shrug*

"We may have to have to agree to disagree."

Yeah...*sigh*...I guess so.

I know you've spent some time on this script and have a vested interest in it...I'm just poking holes into it's practicality. Don't take it personally. =)

My argument from the start has been strictly taken from a practical point of view. Not from a point of failure view.

In the real world, which solution would be the most practical? Adding more javascript or just replacing the input types? Both accomplish similar results but the latter provides less production overhead.

From my point of view if a designer came to me with this I would scrap it. Client side validation and this script have the same end results. Correct password the user proceeds - invalid password the user retypes.

This script is not adding any value to the form process...except an extra unnecessary step.

If you want, give Christina over at eleganthack.com a buzz and see what her thoughts are.

I like your thinking on this...I'm just questioning its application.

Posted by christina Friday, November 1, 2002 at 10:17 AM

Hello,

I think you two are talking about two different things and aren't listening very closely to each other.

Dan is suggesting an occam's razor-- just let users choose to see the password as typing, via a regular input field. If it's a secure site, they could go to a different page, once warned to make sure no evil alien spies are peering over their shoulder. I think this is a great solution and wish all sites would implement it.

Chad has develop[ed a tool to allow users to "debug" their password choice-- it is form independent, so you can use it with any website.

I think this early tool isn't as robust as it could be, and thus looks like a a solution similar to Dan's. And since JavaScript is bulky and instable, I can see why he thinks it should be made more simple.

However, Chad, if you added testing for the issues you outline in your excellent initial post such as key combinations, it could be a nice tool. Perhaps sites could send folks to it when they are picking a network password or if they accidentally mismatch passwords two or three times in a row.

Finally the disclaimer is in black and beneath the boring version stuff (I never read that, because I have IE 6 on a PC, and very little blows up for me.)

Move the disclaimer closer to the actual fields, before (above) the fields, and put it in red, and I think very few users will miss it.

Posted by dan Friday, November 1, 2002 at 10:25 AM

Christina is so dreamy.

Comment from another site:

Posted by IA? EH. Friday, November 1, 2002 at 12:50 PM One of my pet peeves is the little stars in password fields. Read more in stars and garters »

Posted by Chad Lundgren Friday, November 1, 2002 at 01:25 PM

Christine: Your comment is right on the money. This was version 1, if that. I like the idea of checking keyboard combinations and offering suggestions on improving them. I'd also like to allow people to set the length of the password field: right now, it's limited to 8 characters, which is a good average, but not as flexible as it could be.

I agree the simplest solution is not using asterisks. I just don't see being able to sell that to security types.

I deliberately put the disclaimer where most people wouldn't see it. To me, disclaimers are a necessary evil, and I don't want to throw them in the face of the majority of people who don't need one.

Dan: I did get an odd error the other night when using Movable Type. I assumed it was because I Back-ed to a page that had a redundant comment I'd already deleted. I'll keep an eye on it and see if it re-occurs.