Login Functionality – Back to Basics


It is surprising that so many websites still incorrectly implement the basic, rudimentary and essential elements of login and password functionality. Implementing a slick, secure and stable process really should be straightforward for any development team. However, judging by how poorly some websites continue to do it, it may not be as simple as first envisaged.

So, here are Priocept’s Ten Commandments of Login and Password Functionality:

1. Allow the use of an email address as the username

Don’t expect users to dream up a separate username (or “login ID”), and then have to hunt for a variation that isn’t already taken by another user.  David.Lampkin@priocept.com is just fine for me to use as my username, and it is guaranteed to be unique on every website. Hence, I don’t have to come up with ‘davidlampkin999’, ‘david_lampkin’ or ‘dlampkin’ and then remember what username variation I used when I revisit the same website in a year’s time.

2. Allow the user to optionally set up an alternative username

A user’s email address might be very long and inconvenient to type for frequently used websites. Allowing the user to set an alternative username in your My Account section would help to combat this issue. Mandatory usernames should only be used when they are required for very specific reasons (for example, as a public “handle” on forums, Twitter, etc).

3. Clearly label the login field

On the login page, clearly label the login ID field as “Email or username:”, not as “Login ID:”, so it is clear to the user what forms of login ID are valid. It is amazing how many websites label this field “Username” or “Login ID” when actually an email address is expected.

This stems from an assumption made by the developers that the user will use the website regularly. If you have, for example, an e-commerce website and the user decides to buy something from you once per year, how do you expect them to remember what they used as their “Login ID” 12 months ago, and whether it is their email address or some other string?

4. Password Hints and Secret Questions – ditch them

These are yet another laborious step for the user to enter. They often ask for private data that the user may not feel happy disclosing, or even worse, ask for data such as their “mother’s maiden name” which is easy for attackers to find out. Asking for weak security information like “mother’s maiden name” in return for strong security information, like a password, makes no sense whatsoever.

Instead, use a simple email-based password reset feature for lost password recovery. If you need a second level of security, or a password recovery method that can be used after an email account is lost, use “out-of-band” techniques, like a text message, rather than weak methods like “mother’s maiden name”.

5. Avoid username/password length restrictions and character restrictions

These are unnecessary and it is frustrating for a user when they try to reuse their standard 9 character password only to be told that there is an 8 character limit. It is also irritating to be told that you must include upper and lower case characters, numeric characters, and three special characters, for a website where you have little invested interest and therefore don’t want to use extremely secure and hard-to-remember passwords.

So allow plenty of username and password characters (32 should do it), and don’t enforce impossible-to-remember special character requirements that will only serve to encourage the user to write the password down on a PostIt note!

6. Never store the user’s password in anything other than a one-way hash format

When you ask for the password during registration, clearly state the following:

“We only store your password in an encrypted format. It is not possible for our systems or our staff to decrypt or view it in ‘plain text’ format so we will reset it for you if it is forgotten”.

In doing so you give your user confidence that their password, which inevitably they will be using on other websites, will not be readable by a whole team of people behind the scenes (such as temporary staff, disgruntled employees, third party IT firms with access to the database, etc).

This approach implies that you will never allow a user to recover their password and will only allow them to reset it, and may also prevent or complicate the use of techniques such as “Please enter characters 2 and 4 of your password:”.

7. Always use a password strength indicator

Many users simply don’t realise how insecure it is to use, say, a dictionary word as their password. But they are also easily confused by obscure password character requirements such as X numbers and Y special characters. So guide the user, rather than just imposing rules on them.

8. Make use of temporary account locking

Implement temporary account locking (60 seconds is enough) and email alerting after, say, 5 failed login attempts. Too many websites have little or no protection against “brute force” login attacks.

9. Allow users to change their username

It should be possible for users to change the username of their account (if one has been specified) as well as their password and email address. As an example, perhaps the account is being taken over by a new employee of the same organisation, who wants to retain account or order history rather than creating a second account. Or, perhaps the username was a company name and the company has been re-branded.

Implementing this feature will mean that you will also need to introduce a human-readable (and read-only) account number or similar identification which is permanent and remains static as the username changes. In other words, the account number identifies the account, while the username is just a security credential.

10. Notify users when security related actions occur

Always email the user to notify them of security related actions including password resets, changes to usernames, email addresses and passwords, or account locking due to multiple incorrect login attempts. Include instructions and contact details to use in the event where it is apparent that the account has been hacked.

As we said, these are basic and fundamental elements of  login functionality development. Go ahead and pick three websites at random and see how well and how consistently they have implemented the above!

Leave a Comment

(required)