- Issue created by @alexpott
- 🇬🇧United Kingdom catch
Opened the follow-up to the follow-up postponed on this issue; ✨ Notify users without outdated phpass passwords that they need to reset their password Postponed .
📌 Replace custom password hashing library with PHP password_hash() Fixed is part of 10.1.x. This issues adds the phpass module to handle legacy passwords.
Copying @catch's comment #1845004-255: Replace custom password hashing library with PHP password_hash() → in lieu of writing an issue summary...
For each site, there is a window between them first installing a version of Drupal that includes the new password hashing algorithm, and when they uninstall the phpass module (or have to install the contrib version explicitly if we've dropped support but they haven't). If that window is two years or five years, then their users just have to log in once during that window to get a new password hash. If they haven't, they'll need to do a password reset. Long login cookie lifetimes could mean that their users don't have to log in for months after they initially update, so it really needs to be years not months to have a chance of catching even most active users on a site.
IMO this is not an easy concept for site owners to understand, much less site visitors - the fact that the hash can only be updated when the user actually logs in and the way this is spread over time, so it'd be quite possible for sites to uninstall the module, lock out their visitors, and not realise what they've done.
For Drupal core / us, there is the point at which we can assume that all Drupal sites should be on 10.1 or higher, this will only be when 10.0, 9.5, and Drupal 7 are out of support. It's very likely that Drupal 7 will be the last of those to go EOL.
Since the old password hashing algorithm is going to be an integral part of the Drupal 7 migration path, then we can't drop it until we move the Drupal 6 and 7 migrations to contrib, and consensus seems to be that this should only happen when Drupal 7 is no longer supported.
However, if we have a major release that supports migrating from Drupal 7, then to allow sites and their users to have a password migration window long enough after they've migrated, I think we should probably consider supporting the old password hashes for one additional major release cycle after the Drupal 7 migration path is moved to contrib.
This would mean:
That way if you go from Drupal 7 to a mid-release major version (i.e. just before the next major is released or maybe just after that), you still have a solid couple of years or more before we lock out all your users.
I just thought of something that might be useful: we could report statistics on how many passwords are hashed with new vs legacy, and present this to the site owner. I think this could be done with a relatively simple database query, given that we only need to check the first three characters of the hash. This would then help indicate whether it is safe to disable the legacy module.
This is definitely worth a core issue. If we decided not to put it in core, it might be a good thing for upgrade status even?
For site owners: 📌 Add counts of legacy password hashes Active
For users who can't log in because phpass has been uninstalled:
Detect the old password hash fallback when Phpass isn't installed, and when it finds an incompatible hash, tell the user 'You haven't logged in for a while, please reset your password'.
Active
10.1 ✨
Last updated
Opened the follow-up to the follow-up postponed on this issue; ✨ Notify users without outdated phpass passwords that they need to reset their password Postponed .