Is NIST updating its password guidelines?

Image of a steel bank vault - Destination Certification

Passwords play a fundamental role in our security, and the National Institute of Standards and Technology (NIST) has recently posted a new draft of Special Publication 800 63B Digital Identity Guidelines. It’s still open for comment, but it’s likely that many of the changes will make it in to the final version. It’s a big document that goes far beyond passwords, but we will stick to the password changes that it proposes.

NIST’s draft password guidance

We’re just going to draw straight from the NIST’s document itself, but first, let’s explain a couple of terms. A CSP is a credential service provider (not to be confused with a cloud service provider), which is an entity that performs identity proofing tasks, like registering and verifying new accounts.

A credential service provider (CSP) links these new accounts to authenticators, which are keys or passwords that users input to authenticate themselves. A verifier is an entity that verifies a user’s authentication by challenging the user for their respective authenticator.

Basically, the credential service provider adds a new user to the system and verifies their identity. They attach these identities to authenticators like passwords, which the user then inputs to prove their identity to the verifier. If they pass authentication, the verifier then grants them access to the requested resource, as long as they are authorized. If you set up an account and then log in to a company like Google, the CSP and the verifier can both be Google, but they may be different components of Google.

Here’s NIST’s draft list of password requirements:

  1. Verifiers and 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.
  2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
  3. Verifiers and CSPs SHOULD accept all printing ASCII characters and the space character in passwords.
  4. Verifiers and CSPs SHOULD accept Unicode characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
  5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
  6. 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.
  7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
  8. 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.
  9. Verifiers SHALL verify the entire submitted password (i.e., not truncate it).

The two biggest changes of note are numbers 5 and 6. Number 6 has been coming for a long time, and there aren’t too many systems that require periodic password resets anymore. Still, it’s good for the practice to be completely banned.

Number 5 may come as a shock to a lot of people, because many account registration processes still require a mix of different character types, such as upper case, lower case, numbers and symbols. If this rule comes into force, a lot of organizations will have to overhaul their systems.

One of the main reasons that NIST is making this change is because humans are terrible at remembering complex mixes of characters, like “lbr(&$nuk3j9”. While mixing characters does add complexity, it comes at the cost of being really hard to remember, so people will frequently just add the same special characters as a prefix or suffix to all of their passwords, which reduces the security benefits. A better option is to add complexity in a way that is easier on human memory, such as requiring much longer passwords. A common tactic is to generate a series of random words, and use that as your password, like “saloncontrarysweetschoolhike”. This is a lot easier to remember than “lbr(&$nuk3j9”.

Password managers are another important tool that can help users improve their password security game. With these, a user just has to remember a few important passwords like the master password for the password manager and their device password. All other passwords can be stored in the password manager without the user having to waste their mental real estate trying to remember them.

How different are NIST’s changes?

It’s important to note that these aren’t radical changes—NIST has been heading in this direction for a while. In the previous version of the document, NIST indicated that you “…SHOULD NOT impose other composition rules…” and that you “…SHOULD NOT require memorized secrets to be changed arbitrarily…”

The big difference in the new draft is that they’ve changed the terms SHOULD NOT to SHALL NOT. In the nerd speak that NIST uses, SHOULD NOT basically means “we really don’t want you to do this because it’s bad”, while SHALL NOT basically means “you are not allowed to do this.” So, these aspects have only really changed from recommendations to requirements.

While the changes aren’t huge, they do help us progress toward practical security that works within human limitations.

Image of the author

Cybersecurity and privacy writer.

Would you like to receive the DestCert Weekly via email?

Your information will remain 100% private. Unsubscribe with 1 click.

Page [tcb_pagination_current_page] of [tcb_pagination_total_pages]

>