0

I'm working on a basic password system using the password_hash function, and was wondering about the need for the familiar 'Choose a password with uppercase, lowercase, number and symbol' rules.

PHP's password_hash automatically generates a strong random salt, adds it to the password and hashes the result. Then it outputs a final string that has three sections:

  • The algorithm used and number of times it encoded the data
  • The random salt
  • The resulting hash

These sections are concatenated into a single string:

For example a password 'password' is processed as follows:

$password = 'password';
//using password_hash with Blowfish encryption
    $hashtext = password_hash($password, PASSWORD_BCRYPT);

//user tries to log in with password $login
//which is hashed with the same encoder and salt as contained in $hashtext
if (password_verify ($login , $hashtext )) {
        echo 'Password good';
    }else {
        echo 'Wrong password';
    }

Assume that the $hashtext is stored in a database which later is hacked so that this is read and the encoding type and salt is known. Is the strength of the security now based solely on the strength of the password? ie the hacker sets up a function with the same encoder and salt value and runs through a dictionary of possible passwords until the resultant output is the same as $hashtext, confirming that the dictionary value being checked is the original password.

I assume that the randomness and complexity of the salt alone makes this process probably impractical, but would also making the original password p@55Word really add much to the security?

Yes, I realise that those are terrible choices for passwords!

Any help would be appreciated!

Many thanks, Kw

Kwangle
  • 349
  • 2
  • 15
  • you dont verify the hashed password. You have to pass the $password variable into the function. – user2659982 Mar 31 '17 at 09:56
  • 1
    and why even use a salt to begin with? is this an already setup system you have? Plus, `password_hash()` has the salt built-in. The chances of someone "guessing" the hashed password is so minimal, it's almost silly. – Funk Forty Niner Mar 31 '17 at 10:00
  • I believe this is correct. The first argument in the password_verify function is the password that is being checked. The second argument @user2659982 contains the output of password-hash including the encoder, number of passes and the salt value and the resultant hash. The encoder and salt details are applied to the first argument with password_hash and the result compared to $hashtext. If they match, output of verify-password is true. – Kwangle Mar 31 '17 at 10:02
  • 1
    Here, have a read http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords you'll find most of your answers in there. – Funk Forty Niner Mar 31 '17 at 10:03
  • 1
    *"but would also making the original password p@55Word really add much to the security?"* - The hash is only as secure as the password someone chooses and that is beyond anyone's control if someone chooses "password" or "abc123". At best, you'd need a function that will check if a password contains an uppercase letter, a number, a special character and so on with a minimum amount of characters and inform the user that they password is weak (or strong); there are methods out there that do that already. – Funk Forty Niner Mar 31 '17 at 10:06
  • @fred -ii- Using a salt improves security as it uses values much more random than human choices of memorable passwords. This used to be added manually by the user using a randomisation system of their choice, but the password_hash function now does this randomly and is the recommended approach for strong security. – Kwangle Mar 31 '17 at 10:06
  • 1
    Sure, but again; the salt's built-in the `password_hash()` function and was deprecated in PHP 7.0; did you not read the manual? http://php.net/manual/en/function.password-hash.php and again; the hash/salt are only as strong as the password itself. – Funk Forty Niner Mar 31 '17 at 10:07
  • @fred Yes, I read the manual which states that manual salting is deprecated as the password_hash function handles this automatically. I understand how this function works and was simply questioning the value of using complex password in light of the salting complexity. – Kwangle Mar 31 '17 at 10:13

1 Answers1

1

Salting, key-stretching, and password complexity rules have their own purposes and are not related to each other. The password_hash() function...

  1. adds a salt, to prevent the usage of rainbow-tables
  2. makes the password hashing slow, so brute-forcing becomes much more expensive

➽ makes sure, that there is no easier way to find the plaintext password, than with brute-forcing.

All these measures won't help if a user chooses a very weak password like 1234, because this is one of the first combinations an attacker will ever test. That's why password complexity rules where invented, in the hope that the users will choose stronger passwords.

This leads to the question, if such password complexity rules really make the passwords stronger (but this is independend of questions about hashing techniques). Here the discussion becomes a bit opinion based.

It is my own opinion, that complex rules will even decrease password security, because humans can't remember tons of strong passwords, and because they can interfere with good password schemes. People can get very inventive to circumvent such rules, the password Password-2017 will match most rules but is of course a very weak one. So my advice is to enforce only those two rules:

  1. Require a minimum length of 8 characters for a password.
  2. Make a list of the most common passwords and reject them. The minimum length will already rule out a lot of those passwords.
martinstoeckli
  • 23,430
  • 6
  • 56
  • 87