Modernize password policy, user authentication, and session lifecycle management

Problem/Motivation

A Drupal installation should, by default, conform to the best practices of account security. At present, it does not.

Background

In June 2017, the United States "National Institute of Standards and Technology" (NIST) released an updated version of special publication 800-63, which contain guidelines for user authentication and session lifecycle management. These guidelines are only intended for U.S. government systems, but in practice they have functioned as a de-facto industry standard for account security since first published in 2004. Last year's update was both eagerly anticipated and then widely promoted by the security community, mainly because it changed several recommendations—this time based on research and input from security professionals instead of the opinions of a few government officials—that had for years given rise to ineffective practices in the areas of password management and user authentication.

For almost a decade, from 2005, Drupal seemed to be ahead of industry standards in account security practices. Some examples of this would be the password strength meter and the progressively more robust hashing for passwords stored in the database. However, in the last few years, Drupal has failed to keep pace with some of the key developments in the field, which are well synthesized by the new NIST guidelines.

SP 800-63 has three parts, but the one that seems especially relevant to Drupal is 800-63B, which pertains to authentication and lifecycle management for the most common use case of Drupal. Therefore, I have put together a list of guidelines from that document. As of February 11, the list contains all items from section 5.1.1.2 "Memorized Secret Verifiers", a few items from 7.2 "Reauthentication", and a list of Multi-Factor Authentication (MFA) services provided by Drupal contributed modules (NIST guidelines either recommend or require MFA for digital services depending on a risk assessment). If this proposal is accepted, I will add and research the remaining guidelines from 800-63B, mostly related to session storage in Section 7.

A screenshot of the list is included below; it is also available publicly on Google Drive.

Idea

A Drupal installation should, by default, conform to the best practices of account security. A practical way to carry this out would be to meet the NIST guidelines as far as possible. At present, Drupal 8 is a little under 50% (See the spreadsheet—I scored SHALL as 2 points, SHOULD as 1). The approximate scores, rounded for clarity, are:

• Drupal 8 Core: 30/60 - 50%
• With properly configured contrib modules: 45/60 - 75%

Proposed resolution

Modernize Drupal core's account security measures to meet or exceed NIST guidelines.

• Add a password length requirement.
• Fix unicode handling in the password field.
• Provide or recommend a stable mechanism to force password changes after a data breach.
• Generate passwords when new accounts are created by an administrator.
• Provide a means of vetting prospective passwords against bad values, including previously breached passwords, dictionary words, repetitive or sequential characters, and context-specific words.
• Update the password strength meter to account for modern understandings of strength.
• Offer an option to display a prospective password during entry.
• See if we can test for proper SSL setup.
• See if we can test for approved random bit generators.
• Switch to PKBDF2 or bcrypt for the sake of consistency with standard industry practice.
• Make sure that session information is stored securely.
• Get session timeout functionality into Core.
• Get an API for Multi-Factor Authentication into Core, and put some weight behind contrib implementations.
• If we want to be ahead of the game again, investigate implementing a Zero-Knowledge Password Proof system like SRP, which looks totally awesome! It is not mentioned anywhere in NIST 800-63 except in the appendix with the abbreviations and definitions, but if password-based authentication has a future I think this might be it.

Remaining tasks

Not sure

User interface changes

This would require a new administrative screen or two for settings related to account security, including minimum password length, password vetting processes, password strength requirement, session timeout length, etc.

API changes

Not sure

Data model changes

Not sure