Making Standards
“The wonderful thing about standards is that there are so many of them to choose from.” This familiar saying is attributed to legendary computer scientist Andrew Tanenbaum, who inspired Linus Torvalds to create Linux, and it sums up many of the complexities we face in the daily management of IT systems. Some standards support each other; some oppose each other, and some compete with each other for our time and attention. Standards issued by regulatory bodies are often mandatory for organizations they regulate, but there are also major standards issued by entities whose job it is to, well, make standards.
For an example of standards in action, you have to look no further than reusable account passwords, something I’ve written about often here. Different standards bodies in different geographies and industries have defined different standards for how we should use passwords, including the strength, complexity, and lifespan that should be allowed. You may be required to follow a specific standard, or you may have the freedom to choose your own. If the former, you can probably close this browser tab, since you’re stuck with whatever standard you use. If the latter, though, keep reading.
Who’s NIST, and What Do They Do?
The US National Institute of Standards and Technology (NIST) is a good example of a standard-setting body. In fact, it was formerly known as the National Bureau of Standards. As both names suggest, its job is to define and evangelize standards for various things. The NIST website currently lists more than 32,000 published standards applicable to various fields, about 1400 of which pertain to cybersecurity. US federal and state government agencies often require compliance with particular NIST standards in various fields. For example, you’ve probably run across FIPS 140-3, “Security requirements for cryptographic modules,” since every major operating system and cloud vendor has certified their cryptographic modules as meeting it. Why? Because US agencies aren’t allowed to buy products that don’t meet the standard.
NIST also publishes advisory documents that aren’t exactly enforceable standards but are used as benchmarks or inputs to other standards and regulations. One example is NIST Special Publication 800-63, Digital Identity Guidelines. This is actually a set of four documents. The second in the series, SP 800-63B, is titled “Authentication & Authenticator Management” and it’s been generating a lot of press after the September 2024 release of its most recent draft. That’s because NIST is essentially saying that many of us have been managing user passwords wrong and need to cut it out. The draft documents are written to apply to “credential service providers,” or CSPs, meaning entities that issue passwords. In the context of a modern Microsoft 365 implementation, that means your organization.
Why Make Changes Now?
The 2017 edition of SP 800-63B recommended complex passwords, with uppercase and lowercase letters, special characters, and numbers, and it recommended that CSPs force users to change passwords regularly. You’ve undoubtedly seen the effects of this recommendation: it seems like every application and website on the planet has applied these rules, often with a poor user interface. However, it turns out that those recommendations don’t seem to have done much to improve credential security. Forcing users to make their passwords complex leads people to reuse the same password on multiple sites, which overall reduces security for that user significantly. Frequent password resets lead to the same problem—if you force users to reset their passwords every 60 days, some of them will just change their old password of “P@ssw0rdSep24” to “P@ssw0rdNov24” and go on with their day.
Password-cracking tools have improved since 2017, also, powered by ever-faster computing (particularly GPUs) and the network effect of major breaches, which put large pools of known passwords and their hashes out into the world.
What’s Changed?
Before we get to the recommendations, it’s worth pointing out that the language used in standards documents tends to be very specific. If the document says “x SHOULD NOT do y” that means that the implementer is free to do y, or not, but the standard recommends against it. If the document instead says “x SHALL NOT…” or even “x MUST NOT…”, that’s considered to be an enforceable requirement and not just a suggestion.
The current draft of SP 800-63B has some significant changes from the previous version. Section 3.1.1.2 of the draft sets out the following requirements:
- Passwords must be at least 8 characters long, and CSPs are recommended to require at least 15 characters.
- CSPs should allow a maximum length of at least 64 characters.
- Passwords should allow printable ASCII and Unicode characters.
- CSPs may not apply password complexity rules.
- CSPs may not require scheduled password changes. They should only force a change if they suspect that a credential has been compromised.
- CSPs may not require the use of knowledge questions (“What was the make and model of your first car?”)
- CSPs must check suggested passwords against a blocklist of known bad passwords (including dictionary words and previously cracked passwords)
- CSPs must implement rate limiting to guard against password spray and dictionary attacks.
There are additional requirements around password storage, the use of “recovery code”-style passwords, and authenticator apps, but I’ll save that discussion for another column.
What Should You Do?
If you’re already familiar with Microsoft’s best practices for password management, you’ll notice that many of the NIST changes track things Microsoft has already been recommending (or enforcing); you may not actually have much work to do here.
First, keep in mind that you may not have to do anything! Microsoft’s own password recommendations call for a minimum length of 14 characters with no special complexity requirements, and that’s what Entra ID implements by default. If you haven’t changed the default policies, you’ve already got a good start on meeting the new NIST requirements. It’s a good idea to review all of Microsoft’s existing password policies for Entra ID users.
Second, you should familiarize yourself with how Entra Password Protection works. Deploying it properly will help you screen out known-bad passwords. You should deploy it on any on-premises domain controllers you have. Whether or not you have a hybrid environment, you should customize the list of banned terms to include the name of your organization and any terms specific to it that a user might include in the password.
Third, if you’re requiring periodic password resets, quit doing that. The default M365 policy applied to tenants created after 2021 sets passwords to never expire so you may not have to do anything to implement this change.
Fourth, consider carefully whether it’s worth requiring users to choose new passwords that meet your updated requirements. If you have more than a handful of users, you will want to avoid forcing large numbers of users to suddenly reset their passwords. All that does is create noise and chaos. You’ll have to decide how to balance the need to replace possibly weak passwords with the support burden of forcing widespread changes. If need be, you can force expiration only for specific users using a script like this.
Finally, you should consider whether moving your tenant and users to a passwordless solution makes more sense. Now that Entra ID supports APIs for provisioning FIDO2 keys for users, you can automate this process; even if you choose not to do that, using passwordless authentication for high-value or privileged accounts is an excellent step towards hardening your tenant.
