US NIST Password Guidelines review

The US National Institute of Standards and Technology issues and periodically updates standards documents related to security practices. A new revision of NIST Special Publication 800-63, released in June 2017, reflects changes in recommendations related to authentication using passwords, known as "memorized secrets" (see 800-63B, especially sec. 5.1.1). Since the majority of Drupal websites use such authentication methods, and since NIST guidelines are widely seen to reflect industry standards, this comparison may be relevant to individuals and organizations evaluating Drupal.

NIST password guidelines summarized

All guidelines below are from 800-63B sec. 5.1.1.2 unless otherwise noted.

High Importance (SHALL)

Require at least 8 characters in passwords

Drupal core does not provide for limiting of passwords by length. The Password Policy and Better Passwords modules provide this capability, and it would be relatively easy to provide it using a custom module.

Count each Unicode code point as a single character when calculating length

While the vast majority of unicode code points will register as a single character by Drupal's password strength meter, some of the higher groups, such as emoji and mahjong tiles, register as two characters.

Never truncate passwords

Drupal core with the default password hashing algorithm truncates passwords at 72 bytes (as few as 18 UTF-8 4 byte characters). Work to handle this is in this issue.

Site owners may change the hashing algorithm to one that does not have the 72 byte limitation by utilizing a ServiceProviderInterface::alter().

Generated passwords must be 6 or more characters using an approved random bit generator

Whether or not the random bit generator is secure is complicated and possibly dependent on what specific software is running on the server. However, Drupal core does not generate random passwords. If new user accounts are created by an administrator, the strength of your default passwords are dependent on the skill, knowledge and trustworthiness of that administrator; to avoid this, use a module like Better Passwords.

Do not allow users to store password hints

Drupal core does not provide the ability to store password hints.

Do not prompt users to use specific types of information when choosing passwords

Drupal core does not make any suggestion to site administrators to include such prompts. Site administrators should refrain from using Drupal tools like custom blocks for this discouraged practice.

Compare chosen passwords against a list of poor choices

Drupal core does not provide this functionality, but it is provided by the Better Passwords module, as well as the Password Policy and Password Strength modules used together. The NIST guidelines go on to specify that 

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

Rate limit authentication attempts, allowing no more than 100 failures per account (5.1.1.2 and 5.2.2)

Drupal core enforces rate limits on unsuccessful authentication attempts to 5 per username every 6 hours. Drupal core does not enforce the mandatory 100 consecutive failure limit described in Section 5.2.2.

For more control over rate limiting the Login Security module can be used.

Force password change in the event of a breach

Drupal core does not provide this functionality, but it can be obtained with the Mass Password Reset module.

Use encrypted connections whenever a password is requested

For Drupal, as for all other content management systems, this is dependent on the setup of the web server. A valid SSL certificate should be employed to protect Drupal sites. SSL certificates can be obtained for free from various vendors. It is encouraged to serve all pages of a site over SSL. In cases where unencrypted connections are also supported, the web server should be configured to redirect login pages and authenticated sessions to the encrypted https connection.

Store only a salted hash value for each password

Drupal core stores only a salted hash value for each password.

Hash passwords (and salt) using a suitable one-way key derivation function

Drupal core uses PHP's password_hash() function to generate hashes with the bcrypt algorithm. This method utilizes a a password, a salt (generated internally) and a cost factor (iteration count) to increase work effort.

Use an approved one-way hashing function within the key derivation function

Drupal core uses a PHP's password_hash() method. None of the hashing algorithms supported by this function are on the NIST approved list.

Drupal by default uses bcrypt. The site owner may change this to another password_hash() supported algorithm by utilizing a ServiceProviderInterface::alter().

Approved hash function are those detailed in SP 800-107 , Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B], Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185].

Salt passwords with at least 32 bits of data

PHP generates a salt of 128bits for bcrypt. PHP Generates secure length salts for other algorithms.

Store salt and the derived password hashes together

Drupal stores salt and derived password hashes together.

Medium Importance (SHOULD)

Allow at least 64 characters in passwords

Due to truncation the lower bound may be as low as 18 characters for actual password length. Drupal core allows up to 128 characters in password fields. Only the hashed value is actually stored, passwords can be longer than 128 characters however users would not be able to enter them into password fields unless those fields were modified by a module.

Allow any character in passwords, including unicode

Drupal core allows any characters in passwords.

Apply normalization to Unicode characters accepted in passwords

[info needed - does Drupal do this?]

Notify users with Unicode characters in passwords that they may be represented differently by some endpoints, affecting login attempts

Drupal core does not provide this functionality, nor is there any contributed module that provides it.

Guide users to choose a strong password

Drupal core offers a password-strength meter to assist the user in choosing a strong password. The password meter is implemented only as a suggestion, in keeping with the recommendation that no composition rules should be enforced. Password composition suggestions from Drupal core are:

• 12 characters
• lowercase letters
• uppercase letters
• numbers
• punctuation
• different from username

Additional functionality may be obtained from the Password Strength or Better Passwords modules.

Do not enforce password composition rules

Drupal core does not enforce password composition rules. Administrators should refrain from using the Password Policy module for this discouraged practice.

Do not force periodic password changes

Drupal core does not enforce periodic password changes. Administrators should refrain from using the Password Policy module for this discouraged practice.

Allow paste into password fields

Drupal core allows paste into password fields.

Offer an option to display the password until it is entered

Drupal core does not provide this functionality, but it can be obtained with the View Password module.

Use a memory-hard key derivation function to hash passwords for storage

[info needed - is Drupal's implementation considered memory-hard?]

Output should be the same length from the key derivation function as from the underlying one-way function output

[info needed - is this the case in Drupal?]

Stretch password hashes by performing the hash function at least 10,000 times

Drupal 10.1.0 and newer do not use PBKDF2. Bcrypt passwords are hashed 12 times. The higher complexity of Bcrypt provides a similar stretching at much lower work factor counts.

Use an additional secret randomly generated salt stored in a specialized device like a hardware security module

Drupal core does not provide this functionality, nor is there any contributed module that provides it. The definition from NIST is as follows:

In addition, verifiers SHOULD 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.

Multi-Factor Authentication

In addition to a "memorized secret" or password, the NIST guidelines describe several other possible methods of authentication:

• Memorized Secret (Section 5.1.1—i.e. a password)
• Look-Up Secret (Section 5.1.2—e.g. one-time recovery codes)
• Out-of-Band Devices (Section 5.1.3—e.g. communication with cellphones)
• Single-Factor One-Time Password (OTP) Device (Section 5.1.4)
• Multi-Factor OTP Device (Section 5.1.5)
• Single-Factor Cryptographic Software (Section 5.1.6)
• Single-Factor Cryptographic Device (Section 5.1.7)
• Multi-Factor Cryptographic Software (Section 5.1.8)
• Multi-Factor Cryptographic Device (Section 5.1.9)

Multi-factor authentication is required by NIST guidelines for any digital service with even low to moderate risk levels in several areas, including any application in which personally identifiable information (PII) is accessible.

Drupal core does not provide multi-factor authentication, but can be obtained with Two-factor Authentication (TFA) or One Time Password.