Username and Password Usability

Published on June 23, 2007

In all, I probably have at least 20 username and password combinations:

  • 3 free email accounts: Hotmail, Yahoo, and Gmail
  • 3 work related email addresses (one for each air-gapped network I have access to)
  • 2 e-banking accounts
  • Several other protected online resources, such as social networking sites, stock photo sites, video sharing sites, and the likes

It's ridiculous.

To make matters worse, account providers sometimes (unknowingly?) complicate things even more. For example, some assign usernames. This makes it harder for users to remember their usernames, especially when they are made up of numbers. Difficult password systems and password retrieval processes also make matters worse.

In an attempt to manage multiple usernames and passwords, users will:

  • Use the same ones across different accounts
  • Avoid changing their passwords on a regular basis
  • When they do change their password, they go through the trouble of changing all their other passwords to the same one

Even with these measures in place, users still forget their usernames and passwords (mostly passwords). As a matter of fact, it is estimated that about 25%of help desk request calls are for password resets.

Until a better solution becomes available (e.g. biometric authentication), consider the following suggestions for username and password requirements of your Internet resources:

  1. Use Email Addresses for Usernames

    An Internet email address can be used to uniquely identify a user. Almost everyone has one, and most don't forget it. So, use it – just like MySpace, Friendster, and Flickr does.

    Using email address for usernames has an added benefit: you'll already have a means of contacting the users. There is no need to ask for a username and an email address anymore. Just consider them one and the same.

    Obviously, email service providers such as Gmail, Internet Service Providers, and web hosting providers are exempted from this rule. In their case, it makes sense to ask for a username that is not an email address.

  2. Accept Special Characters in Passwords, But Don't Require Them

    In some cases, password systems require special characters. In other cases, they are disallowed due to security concerns (e.g. SQL injection).

    This causes a problem for users who try to keep their passwords the same across accounts. The happy medium is to accept special characters, but not require them. This will make your password system least restrictive, and, thus, most compatible with others.

    The onus will be on the web developer to make sure special characters cannot be exploited. Users will be responsible for making sure their passwords are strong.

  3. Provide Easy Way to Retrieve/Reset Password

    Because it is common for users to forget their passwords, provide an easy way for them to retrieve or reset them.

    One perfectly acceptable approach is to have a list of questions a user can select and provide an answer to. "What is your mother's maiden name?" is something most users should be able to answer correctly.

    Another option, and possibly more effective and secure, is to allow the user to provide their own question and answer.

    Do not base questions on things that may change in the future (e.g. ZIP code, last four digits of credit card, etc.).

    (NOTE: On a particular company's intranet that I was evaluating, their password retrieval system asked its user's to "Enter Verification Word." There was no hint to what the verification word might be. Users can't possibly be expected to recall such information based on such a poorly phrased cue.)

Usernames and Passwords on Intranets

There are different rules for usernames and passwords for intranets.

Aside from the username and password required to log on to the network, most intranet resources can probably get away without having to challenge users for a username and password. This is possible because, in a lot of cases, web developers can obtain the user's logon credentials in an intranet environment. These may be used as the basis of authentication and authorization.

If having to enter a username and password is a must for some reason, then use (possibly even assign) the user's logon ID as their username. Having a username identical to the logon ID means one less thing the user has to remember.

As for passwords, use the same rules applied to the network password. This allows users to maintain the same passwords, if they chose to do so.