[wp-trac] [WordPress Trac] #65144: Passwords: trim() asymmetry between wp_hash_password() and wp_check_password() introduced in 6.8
WordPress Trac
noreply at wordpress.org
Wed Apr 29 06:42:47 UTC 2026
#65144: Passwords: trim() asymmetry between wp_hash_password() and
wp_check_password() introduced in 6.8
--------------------------+------------------------------
Reporter: mkultraware | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 6.8
Severity: normal | Resolution:
Keywords: | Focuses:
--------------------------+------------------------------
Comment (by hbhalodia):
Hi @mkultraware, Thanks for the ticket. I can verify indeed it's an issue.
For a quick check for the usecase, we can use the below snipped as a
plugin and test it out.
{{{
add_action( 'init', function() {
$hashed = wp_hash_password( ' password-to-hash. ' );
$to_check = wp_check_password( ' password-to-hash. ',
$hashed );
var_dump( $to_check );
wp_die();
});
}}}
The output would be `bool(false)`, instead it should be `bool(true)`. This
is because, `wp_check_password` is not handling the leading/trailing
spaces as how `wp_hash_password` does while hashing the password.
To handle is properly for all the usecases, Instead of just adding trim to
line `2858`, we should add the trim to all passwords IMO, but since
`wp_hash_password` adds a unique prefix, then wp_check_password will
satisfy the condition on line, `2856: elseif ( str_starts_with( $hash,
'$wp' ) ) {`, So for adding a patch currently, I am adding it specifically
for the if condition, but we can handle that in PR review and update as
needed.
Thanks,
--
Ticket URL: <https://core.trac.wordpress.org/ticket/65144#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list