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?

  • 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 Oct 28 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 Oct 28 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 Oct 29 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 Oct 29 at 15:17

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.

  • I thought the salt in the wp-config.php file is not used for this case. Isn't the salt extracted from the hash and then using the crypt_private function used in order to generate a hash for comparison? – McJohnson Oct 28 at 16:39
  • how do you extract salt from a hash? As I said in the one before last paragraph, if you can know the salt, either by inspecting the code, or by inspecting the value, it do not provide any additional "security" compared to not having salt at all – Mark Kaplun Oct 28 at 18:01
  • This is not true. Your answer is misleading. The salt used to generate a hash for comparison is derived from the stored hash (in the DB). github.com/WordPress/WordPress/blob/… – McJohnson Oct 28 at 18:05
  • 1
    I explained to you how things actually work, if you prefer to not believe and misread the code, that is ok with me – Mark Kaplun Oct 28 at 22:13
  • 1
    can not point you to the "right direction". this is not a code review site, and if you fail to read correctly the code and understand how it executes there is not match that can be done in the context of this site and how it operates. The answer gives you an overview which is not even specific to wordpress itself on how how such things should (and do) work. If you insist that they work differently while they don't, there is nothing much I can do about it. – Mark Kaplun Oct 29 at 2:32

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.