php - WordPress produces identical hash all the time

admin管理员组

文章数量:1130349

So I was looking at WordPress'es source because I was curious how hashes are compared on the back-end. However, I am at a loss to understand how exactly phpass is meant to produce different hashes for a single input (considering a different, random salt every time).

As in the latest WordPress version, the CMS uses the CheckPassword function as defined:

function CheckPassword($password, $stored_hash)
{
    if ( strlen( $password ) > 4096 ) {
        return false;
    }
    $hash = $this->crypt_private($password, $stored_hash);
    if ($hash[0] == '*')
        $hash = crypt($password, $stored_hash);
    return $hash === $stored_hash;
}

Shouldn't hash have a different value all the time, regardless of the input due to the salt? Is WordPress using a static salt for hashes? If so, where is it defined and how is it being generated?

So I was looking at WordPress'es source because I was curious how hashes are compared on the back-end. However, I am at a loss to understand how exactly phpass is meant to produce different hashes for a single input (considering a different, random salt every time).

As in the latest WordPress version, the CMS uses the CheckPassword function as defined:

function CheckPassword($password, $stored_hash)
{
    if ( strlen( $password ) > 4096 ) {
        return false;
    }
    $hash = $this->crypt_private($password, $stored_hash);
    if ($hash[0] == '*')
        $hash = crypt($password, $stored_hash);
    return $hash === $stored_hash;
}

Shouldn't hash have a different value all the time, regardless of the input due to the salt? Is WordPress using a static salt for hashes? If so, where is it defined and how is it being generated?

• php
• password

Share Improve this question asked Oct 28, 2018 at 15:04 McJohnsonMcJohnson 101 4

• If it generated a different hash with the same input, it would be impossible to check if a password is correct. That's not what salts are for – Tom J Nowell ♦ Commented Oct 28, 2018 at 15:25
• I thought it's based on the same principle as password_verify() - i.e. verifying whether the value is correct, not by 1:1 match. What are salts for if not for that? – McJohnson Commented Oct 28, 2018 at 15:28
• no, salts are a completely different thing, salts prevent you from doing a hash of every password and using those to compare, by making the hashes unique to your site. You always get the same hash but you can't compare it to a long list of passwords without figuring out what the salt was then building a new list from scratch – Tom J Nowell ♦ Commented Oct 29, 2018 at 15:16
• Also that's not how password_verify works either. It's not possible to test if a value is correct without it being a 1:1 match without being able to undo the hashing, and the whole point of hashing is that it's near impossible to undo – Tom J Nowell ♦ Commented Oct 29, 2018 at 15:17

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

The point of hashing a password when storing it in the DB is that it will not be disclosed if anyone got a dump of the DB. There has to be a 1:1 relationship between the password and the hash here as you need to be able to compute the hash of a given password and verify its correctness against the value stored in the DB, something you will not be able to do if there might have been more than one correct result for hashing a password.

Using salts will not make any real difference, as any salt you will add will be constant and added in the same way and there will still be a 1:1 relationship between the password and the value stored in the DB.

The other factor that is actually highlighted when looking at how verify_password works, is that hashes many times contain signature which indicates what type of hash was used to generate them so the software can be able to use the correct hashing when comparing the values. A not careful manipulation of that value is risking that you will not be able to know which hash to use.

Last and not least is the fact that salts are configurable by the user (in wp-config.php) and if you will use a salt when hashing a password, you risk users not being able to ever login again without resetting their passwords, if a salt changes. OTOH if you hardcoded the value in the code, than since it is open source everybody can know the salt which is being used which will make the whole thing pointless.

People that feel like the way wordpress handles hashing is not secure enough for their requirement can always implement their own algorithms and override the wordpress ones.

So I was looking at WordPress'es source because I was curious how hashes are compared on the back-end. However, I am at a loss to understand how exactly phpass is meant to produce different hashes for a single input (considering a different, random salt every time).

As in the latest WordPress version, the CMS uses the CheckPassword function as defined:

function CheckPassword($password, $stored_hash)
{
    if ( strlen( $password ) > 4096 ) {
        return false;
    }
    $hash = $this->crypt_private($password, $stored_hash);
    if ($hash[0] == '*')
        $hash = crypt($password, $stored_hash);
    return $hash === $stored_hash;
}

Shouldn't hash have a different value all the time, regardless of the input due to the salt? Is WordPress using a static salt for hashes? If so, where is it defined and how is it being generated?

So I was looking at WordPress'es source because I was curious how hashes are compared on the back-end. However, I am at a loss to understand how exactly phpass is meant to produce different hashes for a single input (considering a different, random salt every time).

As in the latest WordPress version, the CMS uses the CheckPassword function as defined:

function CheckPassword($password, $stored_hash)
{
    if ( strlen( $password ) > 4096 ) {
        return false;
    }
    $hash = $this->crypt_private($password, $stored_hash);
    if ($hash[0] == '*')
        $hash = crypt($password, $stored_hash);
    return $hash === $stored_hash;
}

Shouldn't hash have a different value all the time, regardless of the input due to the salt? Is WordPress using a static salt for hashes? If so, where is it defined and how is it being generated?

• php
• password

Share Improve this question asked Oct 28, 2018 at 15:04 McJohnsonMcJohnson 101 4

• If it generated a different hash with the same input, it would be impossible to check if a password is correct. That's not what salts are for – Tom J Nowell ♦ Commented Oct 28, 2018 at 15:25
• I thought it's based on the same principle as password_verify() - i.e. verifying whether the value is correct, not by 1:1 match. What are salts for if not for that? – McJohnson Commented Oct 28, 2018 at 15:28
• no, salts are a completely different thing, salts prevent you from doing a hash of every password and using those to compare, by making the hashes unique to your site. You always get the same hash but you can't compare it to a long list of passwords without figuring out what the salt was then building a new list from scratch – Tom J Nowell ♦ Commented Oct 29, 2018 at 15:16
• Also that's not how password_verify works either. It's not possible to test if a value is correct without it being a 1:1 match without being able to undo the hashing, and the whole point of hashing is that it's near impossible to undo – Tom J Nowell ♦ Commented Oct 29, 2018 at 15:17

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

The point of hashing a password when storing it in the DB is that it will not be disclosed if anyone got a dump of the DB. There has to be a 1:1 relationship between the password and the hash here as you need to be able to compute the hash of a given password and verify its correctness against the value stored in the DB, something you will not be able to do if there might have been more than one correct result for hashing a password.

Using salts will not make any real difference, as any salt you will add will be constant and added in the same way and there will still be a 1:1 relationship between the password and the value stored in the DB.

The other factor that is actually highlighted when looking at how verify_password works, is that hashes many times contain signature which indicates what type of hash was used to generate them so the software can be able to use the correct hashing when comparing the values. A not careful manipulation of that value is risking that you will not be able to know which hash to use.

Last and not least is the fact that salts are configurable by the user (in wp-config.php) and if you will use a salt when hashing a password, you risk users not being able to ever login again without resetting their passwords, if a salt changes. OTOH if you hardcoded the value in the code, than since it is open source everybody can know the salt which is being used which will make the whole thing pointless.

People that feel like the way wordpress handles hashing is not secure enough for their requirement can always implement their own algorithms and override the wordpress ones.

本文标签： phpWordPress produces identical hash all the time