User tests: Successful: Unsuccessful:
Joomla 3.2.0 attempted to update the password hashing to something modern, but botched it royally. Since then, we have the passwordhash library in the system and have been handling the $P$
hash format from it. It was made obsolete with the release of 3.2.1, which switched completely to bcrypt. We kept the code around to allow people to login again with their password in a broken hashing format. That has been 11 years ago. Password hashes are updated to the safe method upon login, so a user would only have the old hashes if the website owner didn't update from 3.2.0 to any newer version (remember: 11 years of no updates, including the security issues we had in that time.) and the user didn't login in those past 11 years. If there is a user who all of a sudden wants to login again, they will have to use the reset password feature.
Commit which introduced PHPass: f470b38
Commit which removed it again: 01f2d71
The rest of the changes are deprecated constants which were only kept around for legacy PHP versions.
Codereview
Please select:
Documentation link for docs.joomla.org:
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries External Library |
Labels |
Added:
PR-6.0-dev
|
I have tested this item ✅ successfully on bd1abb0
Status | Pending | ⇒ | Ready to Commit |
RTC
This is the least objectionable one - but I still think we need a way to expose to users how many of their users are potentially invalid after this gets removed (even if they are old users who haven't logged in for like 10 years).
@wilsonge and I talked this one through at the weekend and its a good healthcheck candidate as @brianteeman suggested and has been put on the healthcheck roadmap.
@bembelimen made a great suggestion, why not move it to the compatibility plugin so that it can still work with 6.0 but the healthcheck in 6.0 can be used and then an educated decision made not only from the perspective of admins that will be affected on a site but also the number of active users who still have the wrong hash. Admins can monitor that and email all the users who are affected, then when the vast majority are no longer affected, make the decision when to switch it off. with the clear understanding that its not in the j7 compatibility plugin so they have 2 years to sort it with the assistance of the healthcheck.
This will also be a great test for the removal of things like MD5 hash or any other password change that we may have to do in the future.
@HLeithner is there anything stopping it being a candidate for the compatibility plugin?
We will also be documenting with magazine, developer.joomla.o and joomla.o articles so we reach all the different user groups that might be affected.
@Hackwar we will need details of mitigation in the manual.j.o
Technical it's possible to move part of it and a switch to the b/c plugin.
Status | Ready to Commit | ⇒ | Pending |
I have tested this item ✅ successfully on bd1abb0
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/44237.