On the heels of Microsoft’s updated password recommendations, the National Institute for Standards and Technology (NIST) has come out with its own updated password guidelines. These recommendations parallel many of Microsoft’s recommendations and thus give them extra credibility; in some areas they go further. When two major security industry influencers independently come to such similar conclusions, it’s a strong signal that companies should take a hard look at their password policies – both for their internal systems and their externally-facing services that have an identity store.
Why the NIST document matters
What is this new NIST publication? SP 800-63-3 is titled “Digital Authentication Guideline”, and it defines requirements to satisfy four Levels Of Assurance (LOAs – the degree to which you’re sure an entity is what or who it claims to be). One of the documents, SP 600-63-3B, is titled “Authentication & Lifecycle Management” and focuses on password guidance.
Why is this document so important? One of NIST’s many duties is that it provides guidelines for the public sector, in other words all the applications in the federal government. Many of the guidelines are recommendations only, but a number of them are requirements that all applications must follow. That’s a broad reach of influence – but it’s even wider than that, because many other industries and companies follow these guidelines.
Let’s look at the NIST recommendations, how they compare with Microsoft’s recommendations, and where NIST goes further. A common theme in both sets of recommendations is greater user friendliness, especially when the recommendations will enhance security or when existing unfriendly policies don’t enhance it. Research has shown that the harder you make password policies, the greater the likelihood that users will cheat or use a predictable method (1, 2, etc.) that’s easily hacked.
NISTencourageslongbuteasytorememberpassphrases
NIST now requires an 8-character minimum, which isn’t radical, but they also now require a greater than 64-character maximum to encourage passphrases. This is one of the themes of the document: strengthen the systems so they can handle stronger passwords in a way that’s easier for the user to remember. In other words, put the burden on the systems – not the users. Along with Microsoft, they also recommend a dictionary of common passwords that can be used to disallow weak passwords (e.g. “passw0rd!”) when the user tries to set them.
Another requirement we’ll all be happy to see is to allow spaces, all ASCII characters, and even potentially Unicode characters (such as emoji) in passwords. Can you imagine using emoji in your passwords? Someone will need to show me some keyboard shortcuts before I attempt that! Spaces can cause trouble because it’s difficult to tell one or two spaces apart, but this is made a bit easier with another new recommendation that the user be able to display the password they’ve entered as long as it will hide again after some period of time elapses. We’ve seen this capability become more common, and I’m happy to see it.
Stop expiring passwords
Both Microsoft and NIST address password expiration, and they both recommend that passwords should not be arbitrarily expired after some interval unless there’s evidence of compromise. In contrast to on-premises identity systems such as Active Directory, most websites have always followed this rule. I’m not giving them credit for being forward-looking in their password policies, however; they just didn’t want the hassles that password expiration would cause their help desks and their customers.
NIST is rejecting knowledge-based authentication (hints) that can be discovered, or brute forced, by an attacker. Let’s face it, most of the bad guys know your mother’s maiden name by now. They also recommend not using compositional rules because it’s too hard for the user and they don’t provide as much security as originally thought.
Time to start moving away from SMS
A big change, and one that’s caused a lot of comment, is the deprecation (“we aren’t going to reject it just yet, but we aren’t going to enhance it any more”) of using SMS as a second factor of authentication. And it rejects outright using a VoIP number (e.g. Google Voice) for the SMS authentication because it isn’t actually a second factor: it’s not something you have. Their concern about SMS in general is that the service isn’t as secure as it should be because it wasn’t designed for this kind of use. Criminals have devised malware that can redirect SMS messages, and SIM swapping allows a criminal to hijack a user’s messages.
Unfortunately, if you’re in an industry that must follow compliance policies such as HIPAA, you can’t just go implement these new recommendations where they disagree with the policies. You must wait, possibly years, until the policies catch up to recommendations.
Do you disagree with any of these new guidelines? It’s a draft specification, and NIST strongly encourages participation and feedback on Github.
