Since 2014, the National Institute of Standards and Technology (NIST, a U.S. federal agency) has issued requirements and controls for digital identities, including authentication, passwords (known as “memorized secrets”), and more via Special Publication 800-63B. The latest revision (rev. 3) was released in 2017, with updates as recent as 2019. Revision 4 is currently open for comment and review, however, revision 3 is still the standard as of the time of this blog post.
These guidelines cover recommendations for users as they create passwords, as well as requirements and recommendations for verifiers (software, websites, network directory services, etc.) that validate and handle passwords.
Certain aspects of the spec are required, while others are recommendations. Not all organizations must adhere to NIST guidelines, although many do (ex. federal agencies, and often those subject to HIPAA, FISMA, SOX, etc.). In general, these guidelines are a good foundation for strong password security across an organization, service, or another form of digital identity workflow.
Gaining privileged access is the primary goal of many cybersecurity attacks, and the password is an important line of defense. Following NIST password guidelines allows organizations to better protect themselves against brute force attacks, credential stuffing, dictionary attacks, and more:
The remainder of this blog will go into the various NIST password guidelines in more detail, but here’s a quick list in case you’re only looking for a high-level explanation:
We’ll get into the detailed requirements and recommendations momentarily, but it’s interesting to first address why some of these changes are being made. As we’ll discuss, one change is that strict complexity requirements have been removed (ex. required special characters, numbers, uppercase characters, etc.). This is because these types of rules have become counter-productive, as users end up creating simpler passwords than if there were fewer restrictions.
As another example, if password requirements are too complicated then users may start writing passwords down and leaving them near physical computers or servers. Users may also start recycling old passwords with minimal changes, such as by only changing one or a few special characters, numbers, etc. while still using the same dictionary words. Users circumventing security regulations is a worse scenario than having slightly less-complex passwords, which has led to the recommended changes.
This blog focuses on the user and organizational standards for password requirements, so Special Publication 800-63B (Section 5.1.1 – Memorized Secrets) should be read by software vendors, services, and verifiers looking to implement NIST password standards in their products.
With that said, let’s jump into the primary requirements and recommendations.
The length has long been considered an important factor for password security. NIST now requires that all user-created passwords be at least 8 characters in length, and all machine-generated passwords are at least 6 characters in length. Additionally, it’s recommended to allow passwords to be at least 64 characters as a maximum length.
As part of the verification process, verifiers should no longer be truncating any passwords during processing. Passwords should be hashed and salted, with the full password hash stored.
Users should also be allowed at least 10 attempts at entering their password before being locked out.
Standards regarding which characters can be used in passwords are important, for both software that verifies passwords as well as for users creating them. All ASCII characters, including the space character, should be supported. NIST also specifies that Unicode characters, such as emojis, should be accepted as well.
Users should also be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters, in addition to simple dictionary words.
Passwords that are known to be commonly used, expected, or compromised should be invalid. For example, passwords contained in known breach lists, previously used passwords, well-known commonly used passwords, and context-specific passwords (ex. the name of the service) should be avoided.
When a user attempts to use a password that fails this check, a message should be displayed asking them for a different password along with an explanation for why their previous prospective password was rejected.
A popular method for verifying against breached passwords is to use the Have I Been Pwned? database, which contains 570+ million passwords from real-world breaches.
As mentioned earlier in the blog, password complexity requirements have led to less secure human behavior, instead of the intended effect of tightening security. With that in mind, complexity requirements should now be reduced, which includes removing requirements for special characters, numbers, uppercase characters, etc.
Another recommendation for reducing complexity, and insecure human behavior, is to eliminate password expiration.
Although password hints were intended to allow users to create more complex passwords, they ultimately caused users to leave hints that practically gave passwords away. To prevent this, password hints shouldn’t be used in any form. This also includes knowledge-based authentication (KBA), such as questions like “What was the name of your first pet?”.
To account for the growing popularity of password managers, users should be able to paste passwords. Previously it was common to prevent the ability to paste in password fields, which made the use of these services difficult.
Regarding two factor authentication (2FA), SMS is no longer considered a secure option. In the place of SMS, one-time code provider/authenticators, such as Google Authenticator or Okta Verify, should be permitted.
80% of breaches involve weak or compromised passwords and the top 10 common passwords still including ‘123456’, ‘password’, and ‘qwerty’. Breach costs will only rise, further emphasizing the importance of your first line of defense – the password.
Using a dictionary of 570+ million known compromised passwords, along with complexity, character substitution, and testing tools, StealthINTERCEPT Enterprise Password Enforcer safeguards your organization from credential-based attacks.
We can identify and prevent weak and compromised passwords from being used, and even provide end-user guidance on how to choose a stronger password. In addition to enforcement, Stealthbits’ Data Access Governance (DAG) solution, StealthAUDIT, also includes a Weak Passwords assessment for organizations using Active Directory.
Start a Free Stealthbits Trial!
No risk. No obligation.