The National Institute of Standards and Technology (NIST), the federal body that sets technology standards for governmental agencies, standards organizations, and private companies, has proposed barring some of the most vexing and nonsensical password requirements. Chief among them: mandatory resets, required or restricted use of certain characters, and the use of security questions.
Choosing strong passwords and storing them safely is one of the most challenging parts of a good cybersecurity regimen. More challenging still is complying with password rules imposed by employers, federal agencies, and providers of online services. Frequently, the rules—ostensibly to enhance security hygiene—actually undermine it. And yet, the nameless rulemakers impose the requirements anyway.
Stop the madness, please!
Last week, NIST released its second public draft of SP 800-63-4, the latest version of its Digital Identity Guidelines. At roughly 35,000 words and filled with jargon and bureaucratic terms, the document is nearly impossible to read all the way through and just as hard to understand fully. It sets both the technical requirements and recommended best practices for determining the validity of methods used to authenticate digital identities online. Organizations that interact with the federal government online are required to be in compliance.
A section devoted to passwords injects a large helping of badly needed common sense practices that challenge common policies. An example: The new rules bar the requirement that end users periodically change their passwords. This requirement came into being decades ago when password security was poorly understood, and it was common for people to choose common names, dictionary words, and other secrets that were easily guessed.
Since then, most services require the use of stronger passwords made up of randomly generated characters or phrases. When passwords are chosen properly, the requirement to periodically change them, typically every one to three months, can actually diminish security because the added burden incentivizes weaker passwords that are easier for people to set and remember.
Another requirement that often does more harm than good is the required use of certain characters, such as at least one number, one special character, and one upper- and lowercase letter. When passwords are sufficiently long and random, there’s no benefit from requiring or restricting the use of certain characters. And again, rules governing composition can actually lead to people choosing weaker passcodes.
Loading comments...
For years, I've pushed back at organizations that have stuck security hampering restrictions on their access controls with the excuse that it's in either NIST SP or PCI DSS guidelines so they have to do it.
I've pointed out that A) as a customer, those requirements don't apply to ME, they apply to the company's own employees, and B) that, being worlds away from modern security guidelines, applying those restrictions to their customers opens them up to all sorts of data privacy risk and liability that they could easily avoid.
Surprisingly, I've actually convinced a number of big organizations to fix their restrictive policies over the years, often with a letter of thanks from their IT departments who had wanted to fix the issues but had been overruled by higher ups that said "if it's good enough for NIST/PCI, it's good enough for our customers".
NIST SP dispensing with the insecure restrictions is a much-needed step here.
Hopefully PCI can follow suit with DSS 4.1 or later; 4.0 (published in 2022) still requires a number, upper and lowercase letters, and a unique symbol in a password of 12 characters or more. At least it also requires MFA (not required before 4.0), although MFA by SMS or email is one of the acceptable methods.
One of the places that I helped "fix" had banned spaces in their passwords. Why? I have no idea. A properly salted hash doesn't care that a string with 0x20 in it visually looks very similar to one without it. Eventually I was able to explain this to the company using some basic math in a way that the decision makers could understand.
They recommend a minimum length of 15 characters. 8 characters is the absolute minimum, but would presumably only be for systems that were both seriously constrained and deemed to be low value.
Also, 8 characters is weak no matter what. In practice, the way most people conform to character class rules do not add significant security, so adding character class constraints doesn't really help. Adding an expiration does nothing at all.