Password policy is an essential building block of authentication. Surprisingly, best practices are a moving target here.

In most information systems, humans are the easiest targets – and yet when it comes to authenticating users, the most common way of doing it is by relying on humans to come up with a complex and hard-to-guess password. It is even more crucial with DevOps and a large number of third-party tools and services with their own passwords. In June 2017, the United States National Institute of Standards and Technology issued the NIST password standards that most users and developers may not be familiar with.

Unfortunately, we as a species are not good at coming up with passwords, and a large percentage of users are just going to choose an easy-to-type and easy-to-guess dictionary word instead of generating a high-entropy random string via a password manager. To try and make passwords harder to break, system administrators and designers usually implement certain requirements for passwords. An example password policy may be:

• At least one uppercase and one lowercase character
• At least one decimal digit
• At least one special character such as !?@#$/
• Change password every 3 months
• Password must be at least 8 characters

However, except for the last requirement – which is the only one in the NIST password standards – the others just restrict the user’s ability to compose a password without significantly increasing its strength. There are even worse examples – you can find a showcase of them on the Dumb Password Rules page.

‘P@ssword1’ is the best password ever!

Bill Burr, former NIST manager, came up with the original document on NIST password standards in 2003, (correctly) connecting password strength to entropy. This document claimed that composition rules to select lower case / upper case / non-alphabetic symbols in a password was beneficial:

Either dictionary tests or composition rules eliminate some passwords and reduce the space that an adversary must test to find a password in a guessing or exhaustion attack. However they can eliminate many obvious choices and therefore we believe that they generally improve the “practical entropy” of passwords, although they reduce the work required for a truly exhaustive attack.

There is nothing wrong with the theory behind this recommendation. However, in practice, users will just pick a password that satisfies the composition rules with minimal effort. If you ask a user to include an upper-case character, most of the time they’ll just make the first character upper-case; if you ask them to include a number, they will just drop a single-digit number (or maybe a guessable double-digit, e.g. birth year) at the end, making the password harder to remember, but not significantly harder to guess. In short: the old NIST password standards were flawed when used in practice.

This xkcd comic strip from 2011 clearly shows the problem. In a 2017 WSJ interview, Burr himself said he regrets these recommendations, too…

Password policies for the real world: the new NIST Password Standards

The updated version of the NIST Digital Identity Guidelines document – originally published in June 2017 – specifies detailed requirements for passwords (memorized secrets) … let’s look at the new NIST password standards for user-specified passwords in detail.

• A length of at least 8 characters, with no upper limit (at least 64 should be supported) and no password truncation.

> 8 characters is the baseline for characters being brute-forceable. Since the functions used in password storage produce fixed-size outputs, the length of the password should not matter until we get into really long passwords (hundreds of characters or longer).

• All characters should be allowed, including Unicode – which should be normalized before storage.

> This significantly increases the difficulty of brute force attacks and allows for more easy-to-remember variance in passwords (even emojis!).

• Password hints (e.g. “What was the name of your first pet?”) should never be used.

> It is easy to find out the answers to such questions with some research. The attacker can then circumvent authentication entirely.

• The system should check passwords against a blacklist (e.g. dictionary words and obvious passwords such as the username).

> Dictionary and guessing attacks can be feasible even if the system – as well as the password storage algorithm – is resilient against brute force attacks, so forbidding them is a good idea.

• User experience: the user should get an idea about the estimated password strength, should be able to paste passwords, and should have the option to view the password as it is being typed.

> These are very useful features, especially for mobile devices and long passwords. Paste functionality is required to support password managers.

Going against the grain

Some of the NIST password standards appear to go against the previous recommendations and well-known “best practices” – let’s take a closer look at them.

• Composition rules – such as requiring different types of characters or forbidding repetition – should not be imposed on the user.

> This goes directly against the previous recommendation; the rationale is explained in Appendix A of the document. Essentially, the main determinant for password strength in practice is length; complexity does not significantly increase by forcing composition rules on the user.

• Passwords should not be changed periodically but must be changed after a breach.

> Periodic password change forces users to come up with new passwords with no real benefit, unless their password got compromised out-of-band; however, that is a breach event.

Of course, the document contains other recommendations for topics such as password storage and rate limiting. Those recommendations are also good to follow.

It will take some time for the new NIST password standards to sink in. Ultimately, however, they should make the lives of both users and developers easier. We cover all of these rules – and best practices on how to implement them – in the Password policy chapter of our training courses. Find them in our course catalog!