NIST (National Institute of Standards and Technology) is set to update its recommendations for authentication and authenticator management as part of a revision to its Digital Identity Guidelines. The collection of documents provides guidelines for developing information security and risk management practices for Federal Information Systems and Organizations (FISMA).
The document on Authentication & Authenticator Management has been getting a lot of interest recently after hacker Tara DiMotta (@BlackRoomSec) drew attention to some of the most notable changes and enhancements proposed in the latest revision. Specifically, the updated guidelines for password verifiers bring some sanity to the previously cumbersome password requirements, making authentication practices more user-friendly and secure.
NIST is moving away from requiring users to change passwords periodically and is also relaxing the requirements for including special characters. Instead, they focus on the importance of longer, more complex passwords. This is because requiring special characters can lead to weaker passwords as users may resort to easily guessable patterns.
NIST states that “passwords must be of sufficient complexity and secrecy that it would be impractical for an attacker to guess or otherwise discover the correct secret value. A password is ‘something you know.’” The proposed guidelines would be used to verify the identity of individuals accessing government computer systems online, ensuring they are registered and have been authenticated previously.
Towards the objective of enabling users to create more secure passwords, NIST is proposing the following password requirements for verifiers and CSPs (credential service providers):
- Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
- Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
- Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
- Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
- Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
- Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
- Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
- Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
- Verifiers SHALL verify the entire submitted password (i.e., not truncate it).
The elimination of the requirement for funky characters will be a welcome change for those who don’t prefer to use them. @BlackRoomSec explained how it leads to predictable and less secure patterns:
Using complexity rules gets you the user psychology of:
Password1
Password2
and so on
Use phrasing instead and allow for spaces, which is important.Humans type phrases with spaces.
NIST also identified a number of other requirements for password for verifiers, including guiding users in creating strong passwords, implementing rate-limiting for failed attempts, supporting password managers and paste functionality, and providing options to display entered passwords for verification. Additionally, they should allow minor mistypes and ensure the use of approved encryption and secure channels when handling passwords. Verifiers will be required to store passwords in a form that is resistant to offline attacks.
After the comment period for SP800-63B ends on October 7, NIST will review the comments received from the public. NIST will then revise the draft based on the feedback and publish a new version of the guideline. The document doesn’t identify a set timeline for this process, but it typically takes several months.