![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 9 years ago
Last modified 2 months ago
#42183 reviewing defect (bug)
wp_update_user() conditional compares a plain-text password to the hashed old
| Reported by: | yudge | Owned by: | SergeyBiryukov |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Users | Version: | 4.5.2 |
| Severity: | normal | Keywords: | has-patch dev-feedback needs-unit-tests |
| Cc: | Focuses: | administration |
Description
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.
Attachments (3)
Change History (12)
@
9 years ago
Uses wp_check_password() and renames a variable to avoid keeping the plaintext password floating around in another variable
#4
@
9 years ago
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!
#8
@
7 years ago
- Keywords needs-unit-tests added
- Milestone 5.1 → Future Release
Patch needs review and testing.
This ticket was mentioned in PR #11714 on WordPress/wordpress-develop by @sainathpoojary.
2 months ago
#9
- Keywords needs-refresh removed
Trac ticket: #42183
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.