The most recent National Institute of Standards and Technology (NIST) guidelines have been updated for passwords in section 800-63B. The document no longer recommends combinations of capital letters, lower case letters, numbers and special characters. Yet most companies and systems still mandate these complexity requirements for passwords. What gives? There’s a bit of an arms race between NIST and compliance regulations. SOX, SOC2, PCI, etc, all have some password complexity commentary. These have been influenced by NIST in the past, and systems have been updated to require combinations of letters, numbers and symbols so that companies who need to attain these compliance certifications can require their users to implement them.
Legacy and Technical Password Limitations
On top of regulations, there are the technical system requirements for passwords. Some have password encryption but no enforcement of character complexity. Some have fine tuning so that the administrator can identify exactly what special characters / letter cases / number combinations are required. And still others were created in the days when storage was at a premium, leading them to still only use the first 8 characters of what you type in as your password anyway. It all depends on what the leading school of thought was when the tool was created and to what compliance regulations the tool manufacturer thought might be needed. The scope of which tools fall under which compliance framework is different for every company. Two companies may be using the same tool, such as Salesforce, but depending on how they use it and who has access, one might fall under SOX and the other not. Over the last decade, the various changes in NIST – the addition of numbers, the assignment of acceptable symbols, and the suggestion of the ideal number of characters – have become available in these different tools in a not-exactly smooth trajectory. Most companies have found their sweet-spot; these are the requirements that *all of our tools can do* that will meet the compliance regulations we need. You can imagine it took some time and negotiation to get there.
The Move to Passphrases
There’s a bit of inertia in updating passphrase requirements at any company because while it’s never just one software tool, just one vendor, or just one set of compliance regulations, it’s still the same number of IT people trying to keep the company safe. Changing out a tool in an enterprise is often a lengthy, painful procedure, so many companies are still running on software designed for back-in-the-day cracker capabilities. User passphrase requirements of complexity have so far been easier to accommodate than password length. NIST’s updated guidelines now recommend that passwords should be rejected if they are commonly used, expected or compromised. NIST has mandated this change because attackers often compile dictionaries of potential passwords, and computing power is fast enough to try lots of combinations. Any “common word or phrase” is likely to be in one of these dictionaries. (The first stanza of a Shakespearean soliloquy or your favorite pop music chorus is likely in there, as well.) Additionally, repetitive or sequential characters are also included in dictionary attacks and should be avoided. Meanwhile, the computing power keeps growing. It used to be very difficult for a script to quickly run a brute force attack through all the possible combinations for an 8-character password. Back in 2000, it might have taken three years to hit on the correct one. But since 2017, it’s taken about half a day to do the same work. So back in the 1990s, eight random characters, changed quarterly, had a good chance of keeping ahead of a determined brute force hacker. With the exponential time cost for adding digits, a 10-character password in 2000 might have taken 800 years to crack, and a 15-character combination in the billions of years. So the various guidelines weren’t discussing length, just content. But now the crackers have machines that can guess 100,000,000,000,000 times per second, and the brute force attacks can break into the 8 character items in a matter of seconds. Even so, the 15 characters are still not guessable in a matter of millions of years. From today’s technical perspective, the best passphrases are the long ones – 15 characters or longer that avoid the dictionary pitfalls noted above. That makes the complexity of the passphrases such that it’s not actually feasible for the hacker to guess against that many character combinations – at least until we make some even faster computing models. At some point, the various compliance regulations will catch up to the length requirement along with all the software updates.
Password Vaults
If 15-character or larger passwords are required, it doesn’t really matter if it’s got a capital letter or number or question mark. Just that it isn’t already in a dictionary. Ease of use then becomes a factor to consider. Ea429%kkpRT22&!8 may be the recommended password for your next change, but some folks will have an issue typing this multiple times a day from memory and then changing it in a few months. If it’s only used via a password vault, memory isn’t an issue. The complex passphrase, which is also long, makes a lot of sense. As long as your legacy systems and compliance needs will accept it.
Further reading
NIST Digital Identity Guidelines Timescales for cracking passwords
Mastering Security Configuration Management
Master Security Configuration Management with Tripwire's guide on best practices. This resource explores SCM's role in modern cybersecurity, reducing the attack surface, and achieving compliance with regulations. Gain practical insights for using SCM effectively in various environments.
