Users cannot log in if Password Compatibility module is not enabled

Problem/Motivation

After a site is upgraded to Drupal 10.1, the new Password Compatibility module lets users log in with existing passwords.

Normally, this module is enabled in a post-update function. There are many things that can go wrong: at least

1. No administrator is logged in when the code is updated, so no one can access /update.php.
2. The site administrator uninstalls the module, not recognizing the consequences.
3. The database is restored from a backup made before the upgrade.
4. The module is uninstalled by importing configuration saved before the upgrade.
5. Another update or post-update function creates an error, so the module is never enabled.
6. The administrator neglects to execute database updates.

If no administrator is logged in, and any of these happens, then is is hard to enable the module and fix the problem.

Steps to reproduce

The following steps illustrate (1) from the previous section:

1. Install Drupal 10.0.9 with the Standard profile.
2. As a site admin, check the available updates.
3. Notice that 10.1.0 has been released. (Currently, 10.1.0-alpha1 is the most recent version.)
4. Decide to upgrade the next day.
5. Log out and get a good night's sleep.
6. The next day, update the code.
7. Try to log in with the existing password. It will not work.

Proposed resolution

Recommend various ways to enable the module:

• Log in as a site administrator using a one-time login link.
• Enable the phpass module using Drush.
• Set $settings['update_free_access'] = TRUE; in settings.php and then visit https://mysite.com/update.php.

We should communicate these options in as many ways as possible:

1. Add a new section, "If you cannot log in", to the release notes, before "Upgrading from Drupal 6 and 7".
2. Move the Q&A section from https://www.drupal.org/docs/core-modules-and-themes/core-modules/passwor... to the change record, so that it is one click away from the release notes instead of two clicks away. Or link directly to that page from the release notes.
3. Expand the text on /admin/help/phpass. At least recommend logging out and logging in before uninstalling the module.
4. Add a warning message to the confirmation form /admin/modules/uninstall/confirm when uninstalling phpass.
5. (followup issue) Consider adding part of the Password Stats module to the Password Compatibility module. This will add a notice to the site status report, and it can be used to update the warning message in the previous point.

Remaining tasks

User interface changes

Before this issue, the text on /admin/help/phpass is

The Password Compatibility module provides the password checking algorithm for user entities created with Drupal prior to version 10.1.x. For more information, see the online documentation for the Password Compatibility module.

This issue expands that:

The Password Compatibility module provides the password checking algorithm for user accounts created with Drupal prior to version 10.1.0. For more information, see the online documentation for the Password Compatibility module.

Drupal 10.1.0 and later use a different algorithm to compute the hashed password. This provides better security against brute-force attacks. The hashed passwords are different from the ones computed with Drupal versions before 10.1.0.

When the Password Compatibility module is installed, a user can log in with a username and password created before Drupal 10.1.0. The first time these credentials are used, a new hash is computed and saved. From then on, the user will be able to log in with the same username and password whether or not this module is installed.

Passwords created before Drupal 10.1.0 will not work unless they are used at least once while this module is installed. Make sure that you can log in before uninstalling this module.

When the module is uninstalled through the admin UI, this issue adds a warning to the confirmation form at /admin/modules/uninstall/confirm:

API changes

None

Data model changes

None

Release notes snippet

TBD