By Neil Turner

Password Usability Perils to Avoid

By Neil Turner

Password usability is simple, right? Ask your users to set their password; then ask them to type it in whenever they need to log in. What is there to get wrong? Well, quite a lot, actually. It constantly amazes me how many websites and applications shoot themselves in the foot with badly thought-out password usability, for instance:

  • Sorry, your password must be at least eight characters long.
  • Sorry, you have to change your password every six months.
  • Sorry, your password must contain a combination of letters, numbers, and special characters.

There is a surprising amount to think about when it comes to helping users set and enter their passwords with a minimum of hassle, so read on to find out to avoid the most common password usability perils.

The Perils of Setting a Password

Usually, you’ll ask your users to set their password during a registration process, or following a transaction after making a purchase (for example, to create an account). Here are some of the most common password usability perils when it comes to password setting.

Don’t Be Too Restrictive

One of the golden rules of password usability is to avoid being too restrictive. Ironically, by being overly restrictive (such as requiring a long password with a combination of letters, numbers, special characters, and different cases), you can often make your site less secure, because users are forced to write their passwords down in order to remember them. Next time you’re in the office, have a look to see how many sticky notes containing passwords are attached to monitors!

Of course, password restrictions ultimately come down to how secure the site or application needs to be. For example, a three-character password would be insufficient if the site needs to be very secure. Still, the more flexibility you provide for your users, the more likely they’ll be able to set a password they can actually remember.

Let Users Know the Rules

Don’t you just love it when you try to set a password for a site, and it’s returned as invalid due to a rule you were unaware of? Worse still, it comes back as not being permitted, with no indication of why this might be! Don’t keep users in the dark—let them know what the password rules are at the point of entry. Outline the minimum password length, and whether any numbers or special characters are required. Importantly, this information shouldn’t be hidden in a separate help page; rather, include it below or to the side of the password entry field, as shown in this example from MailChimp below.

Ask Users to Re-type Their Password

A simple one, but plenty of sites and applications fail to do it. When asking users to set their password, it’s important to ask them to re-type it straight away. This ensures that the password they’ve entered is the one they think they’ve entered. Re-entry should occur immediately after the initial entry, as shown in the Yahoo registration example below.

Show the Password Strength

Rather than a restrictive password policy, encourage users to set a secure password by relaying the strength of the password they’ve just entered. For example, a long password with a combination of letters, numbers, and cases might be shown as strong, while a short one with only letters could indicate a weak password. Users will instinctively try to use a stronger password, especially if you use positive feedback (like showing a little smiley face, or using a red-yellow-green color code). A lot of the big sites are doing this now, such as Yahoo, eBay, and Google; below is an example from the Google Accounts registration process.

Provide Tips on Choosing a Good Password

Most people know that using their name or the street they live on as their password is a bad idea, but it doesn’t hurt to provide some tips and guidance for choosing a good password. Check out the eBay help page for creating a password for some ideas.

The Perils of Entering a Password

Okay, so your users have set their password, and now you want them to enter it each time they log in to the site. Sounds simple, but again there are some usability perils for you to think about.

Allow Users to Unmask Their Password

The vast majority of sites mask passwords on entry, so that the password is never displayed on the screen. Of course, this stops the busybody next to you from snooping on your password, but what if a login is failing, and you want to check that what you’re typing in is correct? This is why it can be a good idea to enable users to unmask their password; MailChimp has starting doing this, seen in the example below.

SitePoint blogger James Edwards has posted a helpful post on how to do just this: Better Passwords #2: “Show Password”. Of course, the password should always be masked by default, with the user determining whether it’s safe to reveal it.

Warn Users When Caps Lock Is On

You attempt to enter your password, only to be denied because the Caps Lock key is on—oops! It makes sense to warn users if they’re attempting to enter their password when the Caps Lock key is on, such as in this example from Microsoft Vista (see—they do some things right!).

For details on how to do this on your sites, have a read through James Edwards’ post, Better Passwords #3: Caps-lock Warnings.

Warn Users if Their Account Is About to Be Locked

As part of your security policy, you might lock accounts after a certain number of failed attempts; the aim here would be to stop another person trying different passwords to access an account, though it often happens to the user of said account. With this in mind, before locking a user’s account, it’s a good idea to warn them that their next failed login attempt will result in this. So, if you were to lock an account after three failed login attempts, you should alert users after their second try.

The Perils of Forgotten Passwords

People will forget their passwords. There’s little you can do about that, but there should always be a route for those users that have forgotten their password to retrieve it. How best to deal with this situation?

Allow Users to Reset Their Own Passwords

It’s a good idea to enable users to reset passwords themselves. That way, there’s no need for intervention on your part. Typically, this is done by sending a password reset email to the registered email account. The user clicks a link in the email, is directed to your site, and asked to set a new password.

Avoid Sending Passwords By Email

Sending users their passwords via email is a bad idea. Emails are generally not very secure; they can be intercepted—and you don’t want some unscrupulous being who has managed to gain access to your user’s emails also gaining access to their password. Rather than sending passwords via email, send a link to the page for setting a new password—and make sure that the link expires after a reasonably short period of time.

Be Careful Employing Password Hints

It can often seem like a good idea to allow users to include a hint to help them recall their password. However, this can be a little bit dangerous: users might simply enter their password (or a derivative of it) as the hint, or employ a hint that makes guessing their password all too easy. If you do want to use password hints, think about asking users for some additional information before displaying it, such as their ZIP code or date of birth.

Allow Users to Write Their Own Security Question

If, for some reason, you can’t send a password reset email, employing a security question can be a good alternative. If you do use this measure, enable users to write their own question. Your list of potential security questions might be irrelevant for some users (for example, not everyone has a frequent flyer number), and users are more likely to remember the answer to a question they’ve created themselves. Provide examples of good questions (like “What was the name of your first pet?”), and ignore the case when it comes to answers: you don’t want a user getting the wrong answer because they entered “spot” rather than “Spot”!


Keep these simple guidelines in mind when designing your password authentication systems, and your users will thank you!

  • Matt

    “you can often make your site less secure, because users are forced to write their passwords down in order to remember them.”

    Not always true. Most attacks occur purely online and not in person, in which case a complex password that is written down will be more secure than “john1960”.

    • Insomn3ak

      I have to agree with this one. Think about the handful of people who have physical access to your desk or personal belongings. Now think about the vast number of people who have access to your insecure password that was cracked by a bot, or sniffed by a keystroke logger.
      I believe its FAR more secure to have a strong password written down somewhere, than to have an insecure password accessible by anyone with an internet connection.
      I personally use a LastPass/YubiKey combo, and it works great. For the past year, I’ve been able to create a unique 20 digit password for every login I have online. They’re all stored on LastPass servers, encrypted with AES-256, and protected by a master password. If someone were to sniff my master password, they would also have to steal my YubiKey in order to gain access the password vault.
      LastPass isn’t perfect yet, there are some usability issues that would keep me from recommending it to my parents, boss, or other non-geek types. However, I’m hoping those will be ironed out in the near future.

  • Roger Spencelayh

    How about this one when setting up my access to a firm offering Card Fraud & Identity Theft Protection (actual entries changed, but the principle remains)
    Enter a Password: A-123/k
    Message: Password must be at least 8 Characters.
    Enter a Password: Pa55w0rd-99
    Message: Password must be at least 8 Characters.
    Duh? Who has the counting problem.
    After contacting them and explaining my concern about their ability to protect my cards and identity if they cannot get a secure? web page to work correctly, they agreed to cancel my subscription. No indication they accepted they had a problem and perhaps should fix it.

  • And what about choosing the password of the user ? This way, the password fits with your idea of a secure password, as you generate it.
    Of course, that makes another new password for the user to remember but he will just write it down on a post-it, as if you just ask him to find a secure password he’s not used to.
    And how can you send back a password to a user that has lost it, as you cannot imagine to store it in plain text in your database (because you’re concerned about security) ? Does that mean that your hash is decryptable ?
    What I usually do is :
    – generate a password that corresponds to my idea of a secure password,
    – send it by mail (ouch!) to the user as he subscribes and store it encrypted in the database with a unique salt for the entire site that is not stored in the database.
    If a user looses his password, I generate another one the same way and of course destructs the old one.
    Is it stupid or causing problems ?

  • Arkh

    More important are the perils of storing passwords. As a lot of user use the same login and passwords for multiple website, you should treat this data as something to protect.
    If you can’t be bothered to protect it, don’t store it and use other means to identify users like OpenID, facebook connect or other things.
    And no, salting and using sha1 is not protecting a password. Check for more information and for an implementation of salting and stretching a password in php.

  • JR

    And for the love of all that is holy, don’t restrict the number or type of characters allowed in passwords. If I want a 100-character, randomly-generated password chosen from all-character-types, then dammit, let me have it. I’m the bloody customer, stroke my paranoia.

    And if you’re going to limit characters, at least have the decency not to put “Passwords must have one number and one capital letter for security purposes” right above the big red “Passwords must be 10 characters or less” error message.

    • Agreed. Just changed my password on LinkedIn, and they limit it to 16 characters! At least they allow symbols though. What’s the point? Any decent web app will only be storing a hash (or 2) of the password anyway, so it’s a completely artificial limit.

  • bedges

    “… you don’t want some unscrupulous being who has managed to gain access to your user’s emails also gaining access to their password.”

    Surely if that happens, emailing a link to the password reset page is just as bad as emailing a password?

    • Louis Simoneau

      Well, not really, as long as the reset link expires after it’s used or after a set period of time has elapsed. If someone’s hitting “forgot my password”, 99% of the time it’s because they want to log in, so as soon as they get the reset link they’ll use it.

  • Ashish Kumar

    Great post!!!!!!!!!

  • Mick

    I was setting up an online business account with my local bank. They required two passwords, each 8 characters. Not ‘minimum 8 characters’ – both had to be 8 characters exactly (which is daft, since it actually reduces the pool of possible passwords). Together with various other restrictions, such as no two adjacent characters identical.

    A lot of the rest of their online banking system was equally badly thuoght out, and was one of my main reasons for taking my business elsewhere.

  • There’s a case to be made for saying it’s more important to ask the person to type their email twice.

    People can make typing errors registering their email. They will then find that they cannot log in using their email and also that the password reminder email system “does not work” either (for obvious reasons).

    I often see this complaint when working with voice of customer surveys.

Get the latest in Front-end, once a week, for free.