The NIST published last June the final version of the Digital Identity Guidelines also known as SP 800-63. This publication was a draft since 2016 and they even asked for comments from the community on GitHub during the summer 2016. All these comments were inputs for the final publication. Many posts on the Internet mention these changes. But I think it is still important to reiterate them since they are not necessarily well known by everyone who is not in information security.
Who is the NIST?
The National Institute of Standards and Technology (NIST) is a non-regulatory government agency of the US Department of Commerce responsible, among other things, to publish standards for federal agencies. The Special Publications (SP) 800 series are well known to be important guidelines in the information security field for private and public organizations. Worldwide professionals value these publications and they are often used to structure their information security strategies.
New Requirements
Since the past two decades and more, we all saw the result of these requirements. A lack of user experience where most users were often able to circumvent the rules. Many studies have demonstrated these requirements were adding little value on the security side. Furthermore, users were often able to find a way around these requirements thus reducing the security goals. There are mainly 3 requirements updated:
Password complexity rules
You know the rule where you have to put at least a lowercase character, an uppercase character, a number and a special character? It’s not a requirement anymore. Studies shown that users were simply using different patterns to respect this requirement. For example, one trick was to replace some letters by numbers or even simpler, to add an exclamation point at the end. These patterns are all well known by hackers and these passwords were not more secure because of the complexity rule. Oh, all characters should also be available, even emojis!
Password Expiration
This is even something audited during common external audits. That moment at work when you receive a notification and you have to change your password. And this, often every 90 days. No more! We all know users were keeping the same password and adding a character at the end. I was the first one to do it because I always thought it was not efficient. It’s better to have one good password for the service than having a weak one changed every X days. However, it could still be possible to force a user to change a password in certain situations. For example, it should be possible to request users to reset their passwords if the service suspect a compromise. So, it is still important to keep a password history.
Password Hints and Knowledge-Based Questions
Financial services are really good with this requirement, mainly for the knowledge-based questions. This is when questions are also asked with a password to complete the authentication process. The main problem with this is the fact that most answers are now freely available online with social media. For the password hint, I never understood this one. I always saw this one as “let’s just give more clues to hackers on my password” so I never used this one.
Recommendations
The next two are interesting recommendations from the NIST:
Common passwords and usernames
With the new requirements, users are not forced to choose specific characters or to change password. However, the NIST suggests that passwords should be validated against a dictionary of well-known passwords and/or a list compromised passwords. This recommendation makes so much sense. For example, if a user is trying to use, “Test123!” would hopefully fail the validation against the dictionary. There are many dictionaries available online. The logic behind that is the fact that hackers are using these dictionaries to find passwords. The situation is also applicable to common usernames such as “admin” or “root”.
Multi-Factor Authentication (MFA) With SMS
At one point, the NIST completely removed SMS as a valid method to implement with the multi-factor authentication. But with the final release, SMS is still supported, but not necessarily recommended. It is theoretically possible to intercept an SMS. However, it is still more secure to implement MFA with SMS than having no MFA at all. The alternative would be to have an app such as Google Authenticator or a solution with push notifications such as Duo.