Hi,
You can change/reset the password from MySQL/PHPMyAdmin section. On that more details you can get from this URL:
Resetting Your Password
shane, did you actually read what the OP wrote?
romerican, if you think it’s reproducible, submit a ticket:
http://trac.wordpress.org/
You mentioned that everything was very good for several weeks… and also said that you changed nothing during this period… So, is there something you changed on server / installed any new plugin or upgraded any plugin?
When you enter your userid and pasword does it throw you out by saying invliad userid / password or it keeps on login screen for a while and then suddenly throw you on the same page you were?
I’ve faced 2nd kind of case on vbulletin (not on wordpress). That was related to browser, and allowed me to login using IE interface. Basically vbulletin guys mentioned that the issue is related to separate procedure of deling with cookie by different browsers.
Thank you both. whooami, I will submit a ticket then as soon as I follow Shane’s suggestion to make sure it’s not a plugin.
== Follow Up 1 ==
Here’s an example of a password value that is clearly not md5 hash
$P$B62RZ1OiObP1WAuTX8XbPhKkl/w33t1
== Follow Up 2 ==
I did recently add the DingShow plugin. It is now deactivated and I will re-evaluate before submitting a bug report.
$P$B62RZ1OiObP1WAuTX8XbPhKkl/w33t1
thats normal, they all look similar to that. I believe thats due to the salting.
This is a strange issue. I am eager to know the result. You tried your system after deactivating dingshow plugin?
I have continued to operate my blog, per normal, both with and without the DingShow plugin. The result is the same: I get logged out and the password value in the database changes from an MD5 hash to something like the example I gave. And the password is changed for a few other active users (registered readers) of the blog as well.
So far I’m unable to isolate any particular action or series of actions which directly cause the change. But it keep happening.
whooami, when you say it’s normal, are you sure? It certainly does *not* look normal to me, at all. It’s not an md5 hash either. Also, 90% percent of the (users who do not frequently login) accounts’ password value in mysql do not look anything like that but instead look like the md5 hashes I would expect to normally find.
Shane, thanks for your interest. I’m stuck in a place where odd behavior continues but I cannot pin down a cause. As a non-developer, I remain paranoid about hacking or injection or I don’t know what, precisely.
I can confirm now that DingShow is *not* the cause. Nor is any other plugin I tested. As far as I can tell, it is WordPress.
For what it is worth, I see this as well and I do not have DingShow or any other such plug-ins installed. I was able to change a user’s password by simply pasting the ASCII hex md5 hash of the password into user_pass in the wpxx_users table, as indicated here, all over the ‘net. That worked. I was then able to log in to WP using the password I had used to generate the md5 hash. Great — so far, so good. But, then I all but immediately went back into the database and saw that the $P$Bxxxx format had been restored. This was observed less than 2 minutes after logging in using the new password. I do not know when it made the change, but it did.
Conclusions:
1. It is normal
2. It is a WP function, not a plugin.
Open issue/question: what methods are used to create the $P$Bwhatever values? If you investigoogle, you’ll find “attack code” samples out there, in dark places, that illustrate the methods, which involve salts and so on. It makes my head hurt, so I’m not going there. Hope I don’t need to. Still, I would be interested in the details, should WP ever choose to share them.
ColinABQ – Thanks for confirming the same behavior.
Surely, this must be a bug. WP cannot intend to change passwords such that users cannot login and lockout blog admins. I’ve been forced to reset passwords in MySQL with disappointing frequency. Fortunately, I know how… but I also know that is not desirable behavior.
Anyone know the story behind the symptoms?
I don’t think it’s a bug … I think it is by design. It is simply a different type of hash, or perhaps encryption. $P and $B are no doubt directives of some sort allowing WP to detect which flavor of password mangling was used, and the rest looks a lot like base 64 — it might even be the original hash, base 64 encoded.
I did not mean to imply that anything was broken for me due to this — WP still works fine. The change does not lock anyone out of anything with my 2.7.1 ‘blog. It’s just different than in prior versions.
