Advertising sustains the DA. Ads are hidden for members. Join today

Password Compatibility module

Last updated on
2 April 2025

This documentation needs review. See "Help improve this page" in the sidebar.

The Password Compatibility module provides the password checking algorithm that was used before Drupal 10.1.x.

Drupal 10.1.x 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.

Sites updating or upgrading to Drupal 10.1x should read the change record for important information.

When Password Compatibility module is installed, a user can log in with an existing username and password. 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.

Following standard security practices, Drupal does not store passwords in the database. Instead, it computes a "hashed password": a string based on the submitted password. This string is stored in the database. When a user logs in, the hashed password is re-computed and compared to the stored value. It is very hard to recover the original password from the hashed version.

Questions and Answers

How does the Password Compatibility module get installed?

When the site is upgraded to Drupal 10.1.0 or later, a database-update function installs the module. After that, the module can be  installed or uninstalled like any other module.

What happens when the Password Compatibility module is uninstalled?

When the module is installed, users can log in with existing usernames and passwords. Once they have done so, they can continue to use those credentials whether or not this module is installed.

Why not keep the Password Compatibility module installed forever?

Keeping the module installed will defeat the security hardening provided by the updated password algorithm adopted in Drupal 10.1.0. User accounts that have not been used since the upgrade to Drupal 10.1.0 will be more vulnerable to brute-force attacks.

Why not update all passwords at once instead of when users log in?

Drupal stores the hashed passwords, not the originals, in the database. There is no practical way to calculate the new hash from the old one. When a user logs in with an existing password, Drupal can calculate the new hash and store it.

How can I tell which user accounts have been updated?

A site administrator can visit /admin/people and sort by "Last access". Any user who has logged in with username and password since the upgrade to Drupal 10.1.0 should have an updated password hash. These users can log in whether or not the Password Compatibility module is installed.

Users who have logged in with some other method, such as a one-time login link, and not updated their passwords, will not have updated password hashes. The most reliable way to find legacy password hashes is with a database query. The updated hashes all start with $2y$, so you can use this query to find user accounts that have not been updated:

SELECT uid, name, mail, status, FROM_UNIXTIME(login) AS last_login FROM users_field_data WHERE pass IS NOT NULL AND pass NOT LIKE '$2y$%' ORDER BY login DESC;

Help improve this page

Page status: Needs review

You can: