NIST: Password Expirations Could Become a Thing of the Past

Michael Del Giudice
| 4/19/2017

As the National Institute of Standards and Technology (NIST) updates its "Digital Identity Guidelines" publication, it is extending the comment period for the parent document of Special Publication (SP) 800-63-3: "Digital Identity Guidelines"to May 1, 2017. The proposed guidance to manage digital identity risk includes new password requirements.

I believe many organizations and regulations approach passwords incorrectly. The updated NIST guidance aligns more closely with password policies that manage the actual risks of password strength. The NIST guidance calls for the following:

  • Allow all Unicode characters, but do not enforce password complexity.
  • Prevent known bad passwords.
  • Eliminate password hints (typically hints are not secure, and users can put clues that make it easy to guess the password).
  • Use multifactor authentication when possible.
  • Require passwords to be a minimum of eight characters and a maximum of 64 characters.
  • Do not require password to expire.

While I feel passwords should be at least 12 characters long and eliminating password expiration completely could be debated, these requirements are an improvement to managing the applicable risks. 

The composition of a password becomes less critical the longer the password gets. You could argue that a password that is 16 characters long and consists of only letters is more secure than a seven-character, randomly generated password. Thinking about how a password might be compromised will help demonstrate why longer passwords consisting of only letters are more secure:

  1. An attacker guesses it.
  2. An employee discloses his or her password to someone.
  3. It is cracked in a brute-force attack.
  4. The password database is compromised.

In the first scenario, a compromised password is mitigated by using passwords that are not easily guessable. This is accomplished by avoiding common passwords, such as "Password1", or season- or geography-based passwords, such as "Bears2017" or "GoCubsGo." The bar for password complexity and length in this scenario isn’t too high, and password protection should be accomplished through strong end-user awareness programs.

In the second scenario, a password could be disclosed through social engineering or phishing, telling it to someone, or writing it down. Preventive measures again include a strong end-user awareness program, as well as helping employees create passwords that are easier to remember. Minimizing complexity requirements and reducing the frequency of password changes increases the ease with which an end user can remember a password.

In the third scenario, you need to consider how a password is going to be cracked in a brute-force attack. Processing power is very inexpensive today, so systems attempting to crack passwords can churn through possibilities at a very high rate of speed. You can combat this by having passwords that take longer to crack – it actually takes a significantly longer time to crack a 22-character password consisting of only lowercase letters than an 11-character password consisting of upper- and lowercase characters, numbers, and special characters.

For the fourth scenario, you can refer to NIST guidance about the best way to store local passwords. This kind of compromise doesn’t affect the end user or password composition.

I’ve never been so bold as to recommend that passwords shouldn't expire. However, after walking through the scenarios above, I understand how the NIST came to that conclusion. It is much better to have 16-character passwords with no composition requirements, because the risk of password guessing (first scenario) or cracking it through a brute-force attack (third scenario) is greatly reduced. The likelihood of an employee writing down a password that is easier to remember is also reduced (second scenario), and eliminating password expiration would have no negative impact on the risk of phishing or a user telling someone his or her password. If an organization’s password database is compromised (fourth scenario), the organization should require employees to change their passwords, as suggested in the NIST guidance (which also discusses how passwords should be encrypted and stored).

The NIST’s new approach may seem surprising to some because it is so different from how we traditionally have talked about passwords. However, it does manage the risks associated with passwords more effectively from my perspective. The biggest challenge to changing the traditional approach to passwords will be regulatory agencies (and the industry in general) that don’t understand how a completely random seven-character password isn’t as secure as a 14-character password of just letters, and that fall back to outdated perspectives on password strengths.  

The new NIST "Digital Identity Guidelines" formally take password management in a new, but necessary, direction. While I envision it will lead to discussion about the efficacy of the requirements, I recommend that organizations strongly consider adopting these standards to improve their overall risk posture while improving the end-user experience.