Password complexity is one of the top conflictual topics of security. According to NIST, many companies may over-complicate their password policies.
In 2003, Bill BURR (NIST) established a set of guidelines for passwords asking for long passwords. Since then, many policies requested these complex, lengthy passwords mixing characters, digits and special characters. Recently, he confessed that he regretted to have written these guidelines. In June 2017, NIST published a more recent version of the NIST 800-63B document. These guidelines are user-friendly.
In a nutshell, if the user defines the password, then it should be at least eight characters long. If the service provider generates the password, it should be at least six characters long and can even be numerical. The service provider must use a NIST-approved random number generator. The chosen or generated password must be checked against a blacklist of compromised values. There are no other constraints on the selection.
On the user-friendly side, NIST recommends:
- The password should not be requested to be changed unless there is evidence that it may be compromised.
- The user should be allowed to use the “paste” command to favor the use of password managers
- The user should be able to request the temporary display of the typed password.
Additional constraints are on the implementation of the verifier. The verifier shall not propose any hint. The verifier must implement a rate-limiting mechanism to thwart online brute-force attacks. The password shall be stored as a salted hash using an approved key derivation function such as PBDKDF2 or Balloon with enough iterations (at least 10,000 for PBKDF2).
Appendix A of the NIST document provides rationales for this simplification. For instance,
Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones.
Or
Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.
A few cautionary notes; the addressed threat model is an online attack. It does not adequately cover offline attacks where the attacker gained access to the hashed password. The quality of the implementation of the salted hash mechanism is paramount for resisting offline attacks. Furthermore, it should be hoped that a theft of salted hash database should be identified and would trigger the immediate modification of all passwords, thus, mitigating the impact of the leak. NIST recommends using memorized secrets only for Assurance Level 1, i.e.,
AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account.
Higher assurance levels require multi-factor authentication methods. The guidelines explore them in depth. It may be the topic of a future post.
NIST is a reference in security. We may trust their judgment. As we will not get rid soon of the password login mechanism, we may perhaps revisit our password policy to make it user-friendlier and implement the proper background safeguard mechanisms.
I wish you a happy, secure new year.