wp_update_user() conditional compares a plain-text password to the hashed old

[yudge]

In file wp-includes/user.php, function ​wp_update_user()
On line 1767:

if ( ! empty( $userdata['user_pass'] ) && $userdata['user_pass'] !== $user_obj->user_pass)

The second conditional is comparing a plain-text password to a hashed version of password, so this would almost always evaluate to true except for the case where the new password itself matches the old hashed password. This block will then evaluate to false and therefore password itself won't be updated. It's a rare case but the logic here is incorrect. And obviously this code block would run when passwords are the same since it's comparing plain-text to the hashed version.

[johnjamesjacoby]

Hi @yudge, thanks for your ticket here. Hello @rinkuyadav999, thanks also for the patch!

I think the most-correct approach is to use wp_check_password() instead of loading the hasher directly. That function includes considerations for backwards compatibility issues, which are especially useful during this password change workflow.

Unfortunately, wp_insert_user() also still expects the $userdata['user_pass'] to be hashed already, so we'll need to use both functions back to back to maintain backwards compatibility through-out the rest of the system.

I'll attach a next-pass patch imminently for deeper scrutiny.

[rinkuyadav999]

Hi @johnjamesjacoby

Yes, that's why i used wp_check_password() in 42183.1.patch

[johnjamesjacoby]

Uses wp_check_password() and renames a variable to avoid keeping the plaintext password floating around in another variable

[johnjamesjacoby]

Yes, that's why i used wp_check_password() in 42183.1.patch

I didn't see the second email come through. Sorry about that. Glad we're on the same page!

[yudge]

Any status update on implementing this into the core?

[yudge]

Any status update on implementing this into the core?

[pento]

Patch needs review and testing.

Trac ticket: #42183