.svg "2024_Full_Logo_Full_Color_SVG (1)"){kind=logo}
“You don’t need to see his identification.”
It’s a classic line. With a flick of the wrist old Ben Kenobi deftly bypasses the identity & access management system of the poor Stormtroopers just doing their job. One would think, in that technological era, so long ago, that more advanced (and less spoofable) methods of authentication would exist. But they bore the same burden we still struggle with today. How do I really know you are you?
Fortunately, the National Institute of Standards and Technology (NIST) is working really hard to figure that out. Last June, NIST finalized a four-volume opus outlining their latest guidelines on identity and access management (IAM). The document suite, known officially as NIST Special Publication 800-63-3, has a lofty goal of establishing secure guidelines for all federal agencies struggling with IAM woes. And honestly, it’s pretty good, but it’s not quite what you probably think it is. If you’ve been told, or repeated, that NIST now says you don’t need a complex password longer than 8 characters, keep reading.
We often get push-back from clients after a test when we cite them for having a weak password policy. “We’re using the default Microsoft complexity rules,” and “NIST doesn’t require complex passwords anymore,” are some of the common complaints. For the last year or so, as 800-63-3 has been slowly released through draft revisions and then a final version last June, those arguments have become more common. The problem is that folks are selectively reading only the sections they care about. (To be fair, I doubt very many folks have fully read the formal standard. Most are just reading the sensationalized and summarized news articles and blog posts from security “professionals” who also didn’t take the time to read the whole thing.) And let’s be honest, security guidelines can be pretty dry, especially from the government.
So before going any further, let me summarize the most salacious points that all those arm-chair social media warriors like to toss out.
- No more forced password changes! Besides, people just increment the number on the end anyway.
- No more password complexity requirements. People just end up using a simple pattern which defeats the purpose.
- Eight characters is long enough for any password
In fact, there is some truth to each of those, but there’s also a lot of nuance and context. 
It’s worth stepping back for a moment and clarifying that for the most part, we’re only talking about 800-63b, which is the third of the four documents. But the other three docs are just as good. For government policies, they’re well thought-out and well written. While any document like this will be somewhat tedious, the authors have done a good job of sticking to the point and avoiding unnecessary verbosity. It’s also interesting to note that this isn’t the first version of this document. 800-63-2 was published in 2013 and retired on schedule in 2017.
But back to the main point. In order to clarify what specific guidance is intended to mean, we must consider the objective of the document. The abstract of the project, outlined in the first few pages of each document, says that, “These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose.”
Read that again. Slowly.
“… requirements for federal agencies implementing digital identity services…” Notice that doesn’t say these are requirements for existing identity services. Also, “…and are not intended to constrain the development or use of standards outside of this purpose.” If you’re not following along, let me paraphrase that for you, “We know that we’ve outlined some contentious stuff in here, stuff that folks have been arguing about for decades. And this is going to create new arguments, so we’re stating from the very beginning that these guidelines have a very specific purpose and shouldn’t be used outside of that purpose. In other words, don’t put words in our mouth.”
Forget what you’ve read on Twitter. These documents were never intended to define how long your Windows password should be. Instead, the authors have carefully reviewed the last 20 years of bickering over authentication, the failures and the successes, and outlined a new paradigm of authentication management. These guidelines are intended for the implementation of new identity and authentication services. And when you read them from that perspective, it makes a lot more sense. If you’re building a new system, follow these steps and you’ll be golden.
Let’s look at some other specific points that are commonly missed by the SEO-chasing blog posts.
Authenticator Assurance Levels (AALs)
This concept is actually taken from previous versions of this document. The idea is that for different types of systems, you may have different levels of required security. To access my bank account online, they should be very clear that I’m the person requesting access, but to read my HOA’s quarterly newsletter, the site really just needs a pretty good idea that I am who I say I am. 800-63b defines three different AALs, each with increasingly more requirements to provide assurance of the identity of the user (Section 4). Most sites that we would consider authentication to be important for, qualify as either AAL2 or AAL3. I won’t bore you with further details, but understanding this concept is critical to reading through the documents.
Memorized Secrets (Passwords)
It absolutely is true that 800-63b says passwords should be a minimum of 8 characters (5.1.1) and up to 64 characters. The same section suggests that complexity requirements should not be used. It’s worth noting here the difference in policy documents between SHALL and SHOULD. In this section the minimum character length uses the verb SHALL, denoting an absolute requirement. However, the guidance to not have complexity requirements uses the verb SHOULD, which implies merely a suggestion. Additionally, the further guidance to not require periodic password changes also uses the verb SHOULD.
What’s more important about this section is what IS required rather than what is not. For example, the guidance says that all proposed passwords SHALL be rejected if found in a list of “commonly-used, expected, or compromised” passwords. It also says that the login attempts SHALL be subjected to rate-limiting, and goes on in 5.2.2 to define suggested methods for implementing this. Additionally, for most applications that fall in AAL2 or AAL3, multi-factor authentication (MFA) is a requirement (4.2.1) rather than a suggestion. The authors of the document clearly present the case that MFA is the standard authentication process of the future.
Password Hash Attacks
800-63b also has some interesting commentary in Appendix A regarding the guidance for password strength. In particular, they outline some of the reasoning for the weakened controls around password length and complexity. I think they fall short here in not clarifying that these points are valid only because they’ve already outlined requirements for MFA and other security controls. But I can at least appreciate their brevity.
There is one more point hidden in Appendix A.2 that again confirms my position on this document being a new paradigm of authentication management. The document explains that offline attacks against hashed passwords is a totally different ballgame and finishes the thought with the following sentence, “the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.” Taken literally, if it’s possible for an attacker to access hashes and attempt to crack them, then the passwords must be “orders of magnitude more complex.” Orders. Plural. Obviously, the authors, at the very end of a long document, finally fell victim to a slight hyperbole and didn’t intend for your Windows password to be 800 characters long. But clearly these guidelines are intended only for online systems with security controls not commonly found in most operating systems.
Summary
NIST SP 800-63-3 is a great document. I encourage you to read through it all. For more information, check it out at https://www.nist.gov/itl/tig/projects/special-publication-800-63. I honestly look forward to the day when ALL systems have complied with its guidelines. But it shouldn’t be considered an “industry best practice” for existing systems unless you have the opportunity to rebuild your authentication processes.
Got Comments?
I’d love to hear what you think. Feel free to leave comments, or jump on to our Professionally Evil Slack Team.
Nathan Sweaney is a Senior Security Consultant for Secure Ideas. If you need a penetration test or other security consulting services, contact him at nathan@secureideas.com.