Lobby username case determines salt/hash and can result in failed logins, seemingly forgotten passwords

[elexis]

On September 27th 2019 user1 reported:

(09/26/2019 05:04:58 PM) user1: if you enter your username and password and log in, then go back and keep the same saved password, you can then set your caps to whatever you want as long as you don't touch the saved password

(09/26/2019 05:06:02 PM) user1: so as i figured, it happened to ittrelles that he changed his caps after saving his password then didn't understand what was happening when he tried to log in again after reentering his password

And:

(10/07/2019 04:38:51 PM) user1: wait.. can't this all be solved by just making the client erase the saved password if the username is changed?

(10/07/2019 04:42:54 PM) user1: it's already necessary that the user remembers the correct username case that the password was salted in... this only matters when someone saves their password with the correct salt then goes and changes the username case and logs in with the still saved password

Most affected should be people who use the same 0ad program and thus reenter the user/pass combination, and people who switch between linux and windows perhaps.

Also it's that there are platform differences in the case handling for nickname registration, represented in r15888 for example.

There are many failed logins in the lobby logs and the people affected might just leave the program if they cant login nor restore the account via forums, so it seems like an important issue to address.

From 2014/2014-09/2014-09-15-QuakeNet-#0ad-dev.log

01:33 < scythetwirler> when Pureon registered, the bot recognized his jid as Pureon@…/0ad

01:34 < scythetwirler> yet whenever I register the jid always changes to lowercase :/

01:35 <@leper> Windows users seemed to send upper case in jids, others just lower

01:43 < scythetwirler> leper: lookup is currently case sensitive..

[elexis]

Also it was reported and reproduced some months ago that an account had login failure immediately after the registration.

[wraitii]

From a quick investigation, one has to re-accept the terms of use to experience this bug (or modify the case in the stored config). So it seems unlikely that this particular issue would affect so many people. I would suggest downgrading this to "Must Have".

That being said, jabberd JIDs are compared in a case-insensitive manner ​https://xmpp.org/extensions/xep-0029.html . So the bug is indeed that the salt hashing seems poorly designed.

The fix seems rather simple. We should lowercase or uppercase user nicknames when hashing. This, however, will break all accounts that are multi-case and/or the wrong-case (see existing comment about migration)

[wraitii]

Pushing to A25, not enough time to do the migration properly.

[wraitii]

2 releases in a row that this doesn't block the release -> it's not a release blocker.

[Stan]

Unlikely to get done for A26

[Itms]

Whenever this change is undertaken, it would be good to change at the same time the password hashing method to libsodium's crypto_pwhash. Changing the method will have the same side-effects on the user experience, combining the change will prevent us from disturbing the users twice.

[Stan]

Push back