Dealing with NIST’s about-face on password complexity

In the last few years, we’ve been seeing some significant changes in the suggestions that security experts are making for password security. While previous guidance increasingly pushed complexity in terms of password length, the mix of characters used, controls over password reuse, and forced periodic changes, specialists have been questioning whether making passwords complex wasn’t actually working against security concerns rather than promoting them.

Security specialists have also argued that forcing complexity down users’ throats has led to them writing passwords down or forgetting them and having to get them reset. They argued that replacing a password character with a digit or an uppercase character might make a password look complicated, but does not actually make it any less vulnerable to compromise. In fact, when users are forced to include a variety of characters in their passwords, they generally do so in very predictable ways. Instead of “password”, they might use “Passw0rd” or even “P4ssw0rd!”, but the variations don’t make the passwords significantly less guessable. People are just not very good at generating anything that’s truly random.

The other argument that’s been made is that putting the onus of generating and using complex passwords on the heads of the end users leaves them with a lot of stress and responsibility that might be better handled in some other way.

These changes in password composition recommendations have been coming at us for a while – generally in articles or posts about how setting overly strict password complexity standards might actually be making accounts less safe. Still, it’s only been since NIST’s fairly recent draft of its Special Publication 800-63-3: Digital Identity Guidelines (https://pages.nist.gov/800-63-3/) that those of us who manage servers have really begun to feel the need to sit back and pay attention. What do the rule changes mean to us? What might we do differently?

While these guidelines primarily apply to government agencies, the same guidance will likely work its way into companies who work with government agencies, have government customers, or simply want to adhere to what is likely to soon be considered best practice.

The Gist of the NIST List

The new NIST guidance on passwords suggests that:

• passwords never expire
• no required character complexity or variety rules be implemented
• the maximum length for passwords be set to 64 characters
• the minimum length for passwords be set to 8 characters
• passwords be checked against known bad passwords, banned lists, etc.
• no hints or knowledge-based questions be provided to someone trying to log in (like “Who was your best friend in high school?”)
• passwords only be changed when forgotten

On Unix and Linux systems, there is no maximum length setting for passwords – no “maxlen” to complement the “minlen” setting. Even so, the likelihood of anyone even trying to set their passwords to use more than 64 characters seems quite unlikely.

As for minimum password length, the suggestion doesn’t mean that you shouldn’t consider setting your minimum password length to greater than 8 characters. I would still go with requiring 12-16 characters, especially if you remind your users that passwords can be fairly arbitrary and still be memorable. A phrase that they can remember like “Can I go home now?” or even “Ineedmorecoffee!” would work.

You can also encourage your users to use truly random passwords — like those generated by some of the password safe products. Passwords don’t have to be easy to remember if they are cut and pasted as needed. The key to this strategy, however, is that they never forget the key to the safe.

Of course, the new guidance is not simply a relaxation of all constraints on passwords. The intent is to move away from complexity that doesn’t improve security to complexity that does. Checking passwords to make sure they’re not dictionary words, clearly based on dictionary words, related to the username, etc. are key to ensuring that they’re reasonably good. And, luckily, for Linux systems administrators, there’s always pam_pwquality. It will run new passwords against a series of checks that include 1) can’t be a palindrome (e.g., racecar), 2) can’t be simply a case change from the former password, 3) can’t be too similar to the old password, 4) can’t be too simple, 5) can’t be a rotation of the old password, 6) can’t have repeated characters (optional), and 7) can’t contain the user’s name. These configurable checks and some guidance provided to your users on how to most easily construct a password that is both easy to remember and hard to guess will go a long way toward keeping you in NIST’s good graces and relieving your users of their password anxieties.

User vs Service Accounts

The new NIST guidelines are intended to improve password security while taking the heat off your end users. They do not, however, need to be applied against all accounts. A former colleague of mine, Ryan Hill, now Director, Systems Engineering at BECU (https://www.becu.org/) suggests using different policies for service/resource (non-human) accounts and user (human) accounts. He encourages shifting user accounts toward the new NIST guidelines that favor length over complexity while pushing service/resource accounts toward greater entropy (lowered predictability) and length since these accounts are rarely used for logins.

Wrap-Up

Relieving users of the need to reset their passwords every few months while steering them toward passwords that are genuinely difficult to guess is likely to be a big step forward and not the big step backward that dropping complexity might have first seemed it would be.