A Drupal installation should, by default, conform to the best practices of account security. At present, it does not.
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.
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:
Modernize Drupal core's account security measures to meet or exceed NIST guidelines.
Not sure
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.
Not sure
Not sure
Postponed: needs info
11.0 🔥
user system
It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.
Changing to the standard issue template → would also help other contributors.
Finally, to repeat the question asked in #6.
Is this still up to date? What in the issue summary still needs to be done?