1
$\begingroup$

I am creating a simple Sign up and Sign in form using PHP. At the sign up, I create hash using password_hash() function and then store it in the DB. At the time of Sign in, initially what I did was created a new hash using password_hash() function again and then compared it with the stored Password hash.

This failed all the time because as I understand now, a new salt is used every time you create a password hash using the password_hash() function. After researching, I got to know that one should be using PHP function password_verify(<plain_text_password>,<password_fetched_from_DB>).

What I don't understand is how come password_verify function knows the salt value that was used earlier at the time of sign up? If the salt is not known then password_verify should also fail like password_hash function when used for comparison.

I read about it further and what I got to know is that when password_hash() function is used to create the hash, it also stores the salt value inside of the hash? For instance, if hash created is abcde12345, then could 12345 be the salt value?

If this is true, then by looking at a hash can we tell that "this" part of hash is actually the salt value? Is the salt value always placed at certain position in the hash? I would appreciate if someone can share an example.

$\endgroup$
1
  • $\begingroup$ Did you read the PHP site completely? In the Return values or see also part, you will notice password_verify() thank takes the current password input and the stored hash and returns T/F ! $\endgroup$ – kelalaka Jun 16 at 19:17
2
$\begingroup$

The output of any normal password hashing function consists of the difficulty settings, the salt, and the digest of the password, encoded to some format that password hashing function specifies. The verification function expects the same format, and simply reads the salt out of it. This site has a good explanation for the Argon2 hash functions. For example, for argon2id (recommended option for PHP password_hash) with password 12345, salt qwertyuiop, 1 iteration, 1024 memory, hash length 32, parallelism 1, the output is $argon2id$v=19$m=1024,t=1,p=1$cXdlcnR5dWlvcA$dSEO3lF0tmBRi3/HZFZqPJGv38CW35xf9Fcs+8ti0yk

You can see the various parameters, separated by $ signs.

$\endgroup$
0
$\begingroup$

Yes, the salt and hash are stored together, and the hash is always stored in a known place - you just need to look up the format for the particular hashing algorithm used to find the details.

The salt isn't intended to be any more secret than the hash, so it's no problem storing them together. The use of salt isn't intended to make a brute force attack impossible if an attacker managed to get a copy of your password database, but what it does is prevent use of pre-computed tables of hashes, known as rainbow tables, and prevent cracking of the same password for many users at once.

Those attacks don't work with a salted password system because everyone who choose "p455w0rd" as their password will have it hashed with a different salt, so the attacker needs to crack it separately for each of them. Still won't take long with a password as bad as that, but much longer than it would without the salt.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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