Also _> Remember to check why we salt with the username and not the password, that seems wrong at a glance but I'm no expert.

cc @user1 @Dunedan

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/2155/display/redirect

In D2747#116000, @user1 wrote:

I do not want to break all current passwords unless we have a plan in place to address that.

Indeed, before merging this we need a proper plan.

If it needs to be a breaking change anyway, why not to remove the whole logic for generating the actual password by hashing the username and password and instead just using the password as password? Wouldn't this result in the same logic as other XMPP clients use as well?

cannot we create option to change the password and all users would be required to change it?
That function would try to hash password both ways to verify old one but saving only with the new way.

Just for the record, a way to alleviate the above issue is:

• Try both hashing methods and match either.
• Store the 'new' hashed password in the DB
• Then at some point we can just compare to the new passwords and be done with it, only breaking the accounts of inactive players.