WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 8 months ago

#42183 new defect (bug)

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

Reported by: yudge Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.5.2
Component: Users Keywords: has-patch dev-feedback
Focuses: administration Cc:

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)

42183.patch (916 bytes) - added by rinkuyadav999 8 months ago.
42183.1.patch (720 bytes) - added by rinkuyadav999 8 months ago.
42183.2.patch (1.1 KB) - added by johnjamesjacoby 8 months ago.
Uses wp_check_password() and renames a variable to avoid keeping the plaintext password floating around in another variable

Download all attachments as: .zip

Change History (7)

#1 @rinkuyadav999
8 months ago

  • Focuses administration added
  • Keywords has-patch dev-feedback added

#2 @johnjamesjacoby
8 months ago

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.

#3 @rinkuyadav999
8 months ago

Hi @johnjamesjacoby

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

@johnjamesjacoby
8 months ago

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

#4 @johnjamesjacoby
8 months 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!

Note: See TracTickets for help on using tickets.