Recently I have been trying to implement my own security on a log in script I stumbled upon on the internet. After struggling of trying to learn how to make my own script to generate a salt for each user, I stumbled upon password_hash.
From what I understand (based off of the reading on this page: http://php.net/manual/en/faq.passwords.php), salt is already generated in the row when you use password_hash. Is this true?
Another question I had was, wouldn't it be smart to have 2 salts? One directly in the file and one in the DB? That way, if someone compromises your salt in the DB, you still have the one directly in the file? I read on here that storing salts is never a smart idea, but it always confused me what people meant by that.
Never use md5() for securing your password, even with salt, it is always dangerous!!
Make your password secured with latest hashing algorithms as below.
For matching with database's encrypted password and user inputted password use the below function.
If you want to use your own salt, use your custom generated function for the same, just follow below, but I not recommend this as It is found deprecated in latest versions of PHP.
read this http://php.net/manual/en/function.password-hash.php before use below code.
Hope these all helps!!
I’ve built a function I use all the time for password validation and to create passwords, e.g. to store them in a MySQL database. It uses a randomly generated salt which is way more secure than using a static salt.
Yes you understood it correctly, the function password_hash() will generate a salt on its own, and includes it in the resulting hash-value. Storing the salt in the database is absolutely correct, it does its job even if known.
The second salt you mentioned (the one stored in a file), is actually a pepper or a server side key. If you add it before hashing (like the salt), then you add a pepper. There is a better way though, you could first calculate the hash, and afterwards encrypt (two-way) the hash with a server-side key. This gives you the possibility to change the key when necessary.
In contrast to the salt, this key should be kept secret. People often mix it up and try to hide the salt, but it is better to let the salt do its job and add the secret with a key.
Class Password full code:
There is a distinct lack of discussion on backwards and forwards compatibility that is built in to PHP's password functions. Notably:
crypt()
, and are inherently backwards-compatible withcrypt()
-format hashes, even if they use obsolete and/or insecure hash algorithms.password_needs_rehash()
and a bit of logic into your authentication workflow can keep you your hashes up to date with current and future algorithms with potentially zero future changes to the workflow. Note: Any string that does not match the specified algorithm will be flagged for needing a rehash, including non-crypt-compatible hashes.Eg:
Output:
As a final note, given that you can only re-hash a user's password on login you should consider "sunsetting" insecure legacy hashes to protect your users. By this I mean that after a certain grace period you remove all insecure [eg: bare MD5/SHA/otherwise weak] hashes and have your users rely on your application's password reset mechanisms.
Using
password_hash
is the recommended way to store passwords. Don't separate them to DB and files.Let's say we have the following input:
I don't validate the input just for the sake of understanding the concept.
You first hash the password by doing this:
Then see the output:
As you can see it's hashed. (I assume you did those steps).
Now you store this hashed_password in your database, And then let's say when a user asks to log them in. You check the password input with this hash value in the database, by doing this:
Official Reference