Practical steps for strengthening your company's password rules

Passwords are a perennial problem.

We rely so much on them to secure our company systems, our secrets, our customers’ private information… and yet we typically leave it in the hands of our users to choose their passwords safely.

That’s why so many people still use passwords like “123456”, “qwerty”, “abc123”, “letmein”, “qazwsx”, “iloveyou”, “trustno1” and, yes, even “password”.

Those are all, obviously, awful passwords and yet horrendously common choices for users.

The problem is that most users seem to come out in hives at the thought of dreaming up a unique, nonsensical jumble of characters to secure their accounts.

One thing you can do to try to reduce the chances of users choosing poor passwords, is to build appropriate rules that are required to be passed for a password to be considered acceptable.

That’s precisely the challenge that has been taken up by the National Institute of Standards and Technology (NIST) in order to build better password requirement guidelines for the whole of the United States federal government.

At the Passwords conference in Last Vegas earlier this month, security and internet privacy researcher Jim Fenton gave a talk (slides available here), describing the proposed improvements to password requirements being developed by NIST.

The hope is that the proposed guidelines will be adopted as a template by organisations and developers outside the US government too.

So, what can we learn right now from the proposals? 

Minimum length. NIST says passwords should be a minimum of eight characters long.  Note that that’s not a maximum minimum, more sensitive accounts may require a larger minimum length for passwords.

The rationale behind this is that online attacks take considerably longer as password lengths increase.

Maximum length. If there has to be a maximum length limit for a password at all, it should be no less than 64 characters.  This should help calm down security conscious folks who are frequently infuriated when a website form tells them that their passwords cannot be longer than 16 characters.

Adopting a maximum length limit of no less than 64 characters encourages users to choose a memorable pass phrase rather than a password.  64 characters was specifically suggested because of its ability to fit on many screen types.

No banned characters. NIST says that all printing characters (and spaces) should be allowed in a password.  You can even use UNICODE characters if you wish, which will no doubt please those addicted to their emojis.

Because the website or app would hash, salt and stretch the password entry, SQL injection attacks should not be a concern.

The allowance of spaces is designed to make it more natural to type in lengthy pass phrases rather than passwords, although – because of the concern that users might inadvertently type multiple spaces – they could be canonicalised to eliminate accidental repeats.

No common passwords allowed. Applications and websites should check proposed passwords against a dictionary of commonly-used and known-bad passwords.  No more “password123”, “il0veyou”, or “baseball”.

Lists of tens of millions of compromised passwords are already available, but dictionaries of that size may be counterproductive and lead to users simply altering “badpassword” to “badpassword1” to waltz around the security measures.

In his presentation, Jim Fenton proposes that a dictionary of approximately 100,000 common/bad passwords is probably acceptable, but more testing needs to be done on this topic.

No password hints. The problem with password hints is that they weaken authentication.  “Rhymes with farce-word”.  If you don’t allow users to store a password hint, there is no chance that it will be accessed (and abused) by an unauthorised party.

No composition rules. Users should no longer be forced to include X number of numeric characters, Y number of symbols, Z number of lowercase letters, etc in their password.  Such rules can lead to a worse choice of password (“P@55w0rd”) than when users are given a freer reign.

No periodic password changes unless evidence of compromise.  Many think it’s a good idea to regularly change your passwords, but evidence suggests that it leads to poorer password choices by users.

Of course, if there is a good reason to change a password then the password should be changed.  But the mere fact that it hasn’t been changed for X weeks or months isn’t in itself a good excuse.

Stop using SMS for authentication. NIST’s proposal advises that SMS-based two-factor authentication be abandoned because of known vulnerabilities, in favour of apps like Google Authenticator or special USB keys.

For more information, including NIST’s proposals about how password hashes should be stored securely, be sure to read their guidelines or check out Fenton’s slides.

NIST’s password requirement proposals still require final approval, but the hope is that they will pass sooner rather than later.

And if other organisations outside the US federal government adopt the guidelines for their own password requirements that has to be a good thing for the security of all of us.