Last modified: 2014-10-30 23:53:32 UTC
Created attachment 16294 [details] Unable to login and reset password: "Invalid hash given" in all cases Greetings! User Yustas is having trouble with login and password reset. He hasn't been logging in for a while. Now, he tries to login, but can't. He has email entered: yustas@yustas.com. He tries to reset password and successfully receives reset email. But when he enters old and new passwords, he sees permanent "Invalid hash given" message (I have attached the screenshot received from him). He tried several browsers and OSes. Please help him. You can contact him directly at the email given, or at talk page at Commons https://commons.wikimedia.org/wiki/User_talk:Yustas
Which Wiki is he using? I note he seems to have a :A: password on commonswiki, but on enwiki user_password is unprefixed, but user_newpassword is :B: prefixed..
The main goal now is to login to Commons. He says he remembers he was activating SUL...
Not completely sure about SUL though. He says years ago he was creating same-username account on several wikis. He says: on commonswiki, enwiki and ruwiki: if he types wrong password, he gets message about wrong password. When he types correct password, the reset procedure is started.
He says there is no email confirmation when he tyes correct password. He immediately gets dialog presented at screenshot.
Well something is definitely wrong... Yustas'es password is :A: type, but has a salt stored with it. That shouldn't ever happen. The password api patch did a trick to pretend un-prefixed hashes were type :A:, even if password salting was used, so the hash would get upgraded to type :B:. I'm guessing something in there messed it up. I'm testing a couple solutions. I think we'll be able to either blank the password and let them use password reset. Or it may be a valid :B: hash, and so we can just change the type. I'm working on a reproduction so I can test it.
(In reply to Sergei S. Rublev from comment #3) > Not completely sure about SUL though. He says years ago he was creating > same-username account on several wikis. > > He says: on commonswiki, enwiki and ruwiki: if he types wrong password, he > gets message about wrong password. When he types correct password, the reset > procedure is started. Yeah, we have a hook doing that, since their on the list of users who's password hashes were leaked. We could remove the username from our hook too, to simplify that bit.
Well, we're not able to properly understand some of the technical terms. Can you please give us some simple instructions on what to do, if needed?
(In reply to Chris Steipp from comment #6) > Yeah, we have a hook doing that, since their on the list of users who's > password hashes were leaked. We could remove the username from our hook too, > to simplify that bit. Ok, I marked that username as having already reset their password, so they shouldn't get the reset form on login. Should be able to login now.
Got it! He says he has successfully logged in first on commons, then on several wikis. Thank you very much!
For the actual issue, I managed to reproduce the effect that caused the problem. A user with type :A: password with a hard expired password, I logged in several times and in one case, the password was updated to :A::<hash>, and I couldn't login. I'm not able to find a reliable reproduction for ending up in that state though. I'm a little suspicious of https://github.com/wikimedia/mediawiki-core/blob/2f491ef504b0489afd8a85d6a145058c29c46e61/includes/User.php#L1230 vs. checking $wgPasswordSalt like in https://github.com/wikimedia/mediawiki-core/blob/2f491ef504b0489afd8a85d6a145058c29c46e61/includes/User.php#L4655 Adding Tyler in case he has ideas.
(In reply to Chris Steipp from comment #10) > [...] the password was updated to > :A::<hash>, and I couldn't login. I think I753c135a would fix that problem. We may need a DB cleanup script and/or the compatibility hack I thought we didn't need. > [...] I'm not able to find a reliable > reproduction for ending up in that state though. Perhaps the user had tried to reset his password by email before attempting to log in with his existing password? That would cause $user->saveSettings() to be called, which to get the string to store in the DB, would call toString() on the MWOldPassword object. Though why would we have :A: hashes in the DB at all?
I think we fixed the general issue, and the specific user is in, so I'm going to close this. Reopen if anything else is needed.
