• I have to process password changes from a remote system in WordPress where the external system calls an endpoint made available by our WP plugin and only provides the UserID and MD5 hashed password, not the cleartext password.

    I can populate the user_pass field in the database for the user with the provided MD5 hash, and trying to leverage the WP mechanism where it will update to PHPass on the users next login, but I’m running into some really strange behavior.

    If the hashed password is 16 characters and all upper case, setting the hash into the database allows the user to login, and the password is updated to PHPass in the database. Similarly if the password is ‘wordpress’, the generated hash can be loaded into the database, and the user can login. If the password is anything else, it fails, either the login screen refreshes with no warning, or a ‘invalid login’ error is displayed.

    This makes no sense to me. Is there some kind of limitation I’m tripping over here? A configuration option I can set to make this work as I expect it to? Is this a bug?

Viewing 1 replies (of 1 total)
  • Moderator bcworkz

    (@bcworkz)

    If the stored hash is 32 chars or less, WP assumes it is MD5. It then hashes the provided login plain text with md5(), then compares with the stored hash using hash_equals(). If true, WP creates and stores a PHPpass hash. md5() returns a 32 digit lowercase hexadecimal number. If the hash you provided isn’t the same according to hash_equals(), the process will fail.

    I’m unsure how hash_equals() works. I’m I don’t know how it would equivocate 16 digit upper case to a 32 digit lower case from md5(), but apparently it will from your description of what works. Whatever you are providing from the remote system isn’t surviving the hash_equals() comparison against a md5() of the plain text.

Viewing 1 replies (of 1 total)
  • The topic ‘Problem setting passwords directly in database when I only have an MD5 hash’ is closed to new replies.