Possible instability related to @passwords. #744
Description
Okay, this is the third time I have witnessed this, and now I have run into staff and now users who have run into this.
Scenarios:
Setting one:
Login screen create new user, they create/pass no problem and log right in.
They log out, then log back in again with the same user/pass they still have in their muck buffer.. and the password does not work.
Admin manually sets their password to the same password they just tried, and it works,. user can now log in normally.
This does not happen every time, it seems to happen at random.
Setting two:
Existing user has lost their password. Staff verify it is them, and change their password with '@ newpassword'
Password reports it is changed successfully.
User can not log in with the password.
Admin uses their input history to run the exact same command over again..
Now the password works.
Setting three:
User decides to change their password themselves.
They change it, it reports password changed.
They go to log back in, password does not work.
old password also does not work.
User cannot log in, admin is called in to change it.
User can now log in.
In all these cases, the user input was confirmed/logged, and in all these cases, the password setting just.. failed, somehow, internally, without any error anywhere we can see.
You can test this with two characters in our case. you can log in with a wizbit, and a normal character, and keep setting their password to the same thing over and over again, and have the second login reconnect each test.
It seems to just randomly.. fail, and set some kind of garbage unknown password.
I actually ran into this months ago, but I just knee-jerked and assumed I had flubbed the input somewhere. But now I keep running into it over and over again, and finally just.. tested it.
There is a problem buried here somewhere.