Personally, I'd say either drop all the deprecated hashes with 4.0 or keep them all until 5.0. IMO there is no point in dropping one and keeping the rest (especially as those are even older than the SHA256 mechanism). Lucky enough, if the DI system and the UserHelper class are set up correctly, it should not be difficult to write a plugin that restores these deprecated algorithms if support is really needed (at least, that was the intent of moving things to use the DI container).

That would mean dropping PHPass and MD5. I have no idea how widely used PHPass is, but as far as I can see, PHPass could still be actively used on 3.x sites on old hosts, right? Regarding MD5: Yes, it is not safe to use for normal usage, but I really like that I can do UPDATE #__users SET password = MD5('password') WHERE id = 42; to reset my password via the DB. I don't know if that is (reliably) possible for bcrypt. The password is rehashed as bcrypt as soon as you log in the next time.

I have no idea how widely used PHPass is, but as far as I can see, PHPass could still be actively used on 3.x sites on old hosts, right?

PHPass, like MD5 and SHA256, are only used for validating hashes of accounts that have not been logged into since the release of Joomla 3.3, five years ago (because the PHP minimum is high enough that BCrypt is reliably available in all environments in the expected format, PHPass was the stop-gap to get from 3.2.1 to 3.3 without screwing up too much more than had already been done).

You don't have the easy-to-use UPDATE users SET password = HASH('thing') query with BCrypt, IMO that's an acceptable tradeoff to removing an insecure algorithm (you change that to a query you copy from somewhere that already has "admin" or "password" or whatever already hashed).

Err, crap. Just remembered PHPass is also the algorithm used toward the end of 2.5 (upgraded from MD5). So I guess realistically if you've got sites still migrating from 2.5 they'd be on either MD5 or PHPass. *sigh*

So then this PR would indeed be the way to go for now. 😉

#12333

We went down this path a whilst back. We need to be careful. I'm not sure if there's an easy way we can add a check into Joomla Update for this (i.e. warn people before they upgrade) or force password resets but I'm in favour of killing off sha256 right now

The only thing to consider is that importing users from other system will not work any longer.

For example I migrated a typo3 installation with 1000+ users without any password rehashing, that was a nice experience. Auto rehash has done the rest. Maybe we can find a way to support old passwords with a plugin?

@wilsonge What do you want to do? As I said, a user who still has a SHA256 password, hasn't logged in for 5 years. All others would already be converted. I don't see this being a bigger issue than any other B/C break that we have. Document it and that's it.

@HLeithner I understand that, but you could create your own authentication plugin. In this case I strongly want to push to remove this, because SHA256 does not seem to be secure AND we are not using it in any way in our core. Keeping it in core to me sounds like an encouragement to use it and that is something that we definitely shouldn't do. Thus if you want to do a plugin to support this, I see that plugin in the 3PD domain. Removing this algorithm to replace it with a complete plugin in core sounds like a very, very bad idea.

I don't mean a core plugin, I only wanted to be sure that its possible to create a plugin that can add a easyway to migrate existing accounts. I'm all for it to remove all legacy algos that are no longer consider to be secure as michael suggested.

In the current state of affairs, UserHelper::verifyPassword() can easily support password handlers added by plugins. Same with UserHelper::hashPassword(). Where you run into trouble right now is the password.handler.chained service is protected so a plugin can't decorate/replace that service in any way (#16953 for that issue) but can at least add a handler via Factory::getContainer()->get('password.handler.chained')->addHandler($handler);.

What's tricky though is UserHelper is all static. While the uses of UserHelper::hashPassword() to generate hashed tokens in the database (i.e. for the privacy requests or password reset system) can more easily be locked to a single hash, the calls in the User class do need some way to be able to specify the hash otherwise you're ending up with multiple hashing and saving operations to get a password with the right hash into the database (assuming the cleartext password is included in plugin events anyway, otherwise you're kind of SOL).

Oh, the other issue with UserHelper::hashPassword() is that the list of supported algorithms is hardcoded in the class if you don't pass it a container service ID as the algorithm to use. And that creates potential issues as algorithms come and go.

So adding a hash for checking is easy and J! rehashes automatically if its not our default. That would be enough in my opinion.

So to recap: This is got the thumbs up of all participants in here so far. Waiting for tests.

Can we merge this now?

@Hackwar Can you update the PR to resolve the conflicts?

I have tested this item ✅ successfully on a003047

works as advertised, after settings password to an sha-256 string, i can't login any more. couldn't find any other side effects. for testing i used UPDATE #__users SET password = '{SHA256}1dc3306a57b440826b02fa275a642c6a20505355352cd812587d5d8eed367b2f:lvzJILfqDyCicSgj' WHERE username = 'admin'; which sets the password to 123

I have tested this item ✅ successfully on a003047

From #JMAD19 PBF, Test OK

RTC

So to recap this a second time ;-) we should remove all deprecated hashing functions and write a pr for j 3.10 checking all user passwords for deprecated hashed passwords.

@wilsonge or would you like to merge this and hope for another PR removing the other hash functions?

I want to keep MD5. Can we simply merge this please? Keep it simple and all that...

Can we merge this now? @rdeutz @wilsonge

@Hackwar not my call, I think the release lead should make a decision on this.

I'm happy to drop this hash only - but there needs to be a way of letting the admin know what accounts are being effectively locked out the site (as the password reset mechanism won't work). I think without that I'm very reluctant to merge this.

I definitely don't mind about leaving the md5 and PHPPass stuff in case there are people upgrading direct from 2.5 as michael mentioned - even if that's not been supported for a long time.

Thanks

Documentation needed: Add notes to release note that there maybe a problen with users not loggedin for 5 years or longer and there password has been created with sha256 hashing