How to make strong passwords

There is a four-volume document available covering how to make strong passwords, published by NIST:

• SP 800-63 Digital Identity Guidelines

This document is in clear written form and definitely worth a read.

There’s also a Q&A session on IEEE Spectrum:

• Q&A: NIST’s Paul Grassi on What Makes a Strong Password

The questions are answered by one of the authors of the guildlines: Paul Grassi.

Other documents that may be relevant:

• SP 800-56A Rev. 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography

• SP 800-56B Rev. 2 (DRAFT) Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography

• SP 800-56C Rev. 1 Recommendation for Key-Derivation Methods in Key-Establishment Schemes

• SP 800-108 Recommendation for Key Derivation Using Pseudorandom Functions (Revised)

• SP 800-132 Recommendation for Password-Based Key Derivation: Part 1: Storage Applications

Main points

• DO require subscriber-chosen memorized secrets to be at least 8 characters in length.

• DO permit subscriber-chosen memorized secrets to be at least 64 characters in length.

• DONOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant.

• DONOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

• DO compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised:

  • Passwords obtained from previous breach corpuses.

  • Dictionary words.

  • Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

  • Context-specific words, such as the name of the service, the username, and derivatives thereof.

  • …

• DO offer guidance to the subscriber, such as a password-strength meter.

• DO implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account.

• DONOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.

• DONOT require memorized secrets to be changed arbitrarily (e.g., periodically).

• DO force a change if there is evidence of compromise of the authenticator.

• DO permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

• DO offer an option to display the secret - rather than a series of dots or asterisks - until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed.

• DO use approved encryption and an authenticated protected channel when requesting memorized secrets in order to provide resistance to eavesdropping and MitM attacks.

• DO store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function.

  Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive.

  Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON].

  A memory-hard function SHOULD be used because it increases the cost of an attack.

  The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185].

  The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output.

  The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each subscriber using a memorized secret authenticator.

  For PBKDF2, the cost factor is an iteration count: the more times the PBKDF2 function is iterated, the longer it takes to compute the password hash. Therefore, the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.

• DO perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.