in both cases you obsfucate the content of your plain text.
Reason i mentioned MD5 is it is alot easier on the system to calculate a hash rather than calculating a AES encrypted value.
The hash is ALOT less safe, then lets say AES, mainly because a hash can have more then 1 result, which is why you do not want to use it to obsfucate personal data like you social security, and/or size of penis.
But on the other hand if what your obsfucating is you first name, and your shoe size, using AES on the plain text is beyond overkill.
I am assuming you wouldn't normally store your salt in the same record as described?
If not, then you go down the path of coming up with an algorithm to add noise to the password before hashing, which could all be reverse engineered. This process typically boils down to trying to do enough to make the effort/reward of hacking the system not worth it.
What is the industry standard for doing this?
I have used md5 hashes in small programs where the risk and consequence is a mere annoyance. I am aware of the issue, and have played with basic forms of salting in the past, say using the record id to add noise.
You have to be able to identify the salt for authentication. In this post, it is described the process.
Specific language functions like PHP's password_hash stores the salt in the same string and it prepends centinels to identify it.
The authentication process is like this:
if( hash_function(user_input_password + salt) == hash_of_the_password_and_salt_in_the_database )
{
OK
}
else
{
FAIL
}
As @_adrian said, the salt should be cryptographically secure. Check the language you are using, in PHP a common way to get cryptographically secure strings is 'openssl_random_pseudo_bytes' (you will need openssl extension I think).
I will not call 'salting passwords' a standard but I think it is the best way to store passwords. Also you should be prepared to update the hash function from time to time. PHP will be including built in argon2 support in version 7.2+.
I don't consider sha256 that great of a pick for password hashing. I haven't had to write a login system in a while, last time I did I used bcrypt (although apparently there's scrypt now?). Best password hash functions are the adaptive kind.
MD5 is only good for stuff like generating checksums of files. Don't use it to hash your passwords kids.
Wait, do some developers actually not know this? I thought this was an issue back in the early days of web databases, I thought everyone had got the memo by now?
I would actually not use the default values in the third parameter. You should adjust the cost value of the has so that it takes somewhere in range of 0.2s .. 0.4s to hash it. Which highly depends on your hosting environment.
What I am referring to is:
$hash = password_hash($password, \PASSWORD_BCRYPT, [
'cost' => 12,
]);You misunderstand. Encryption is different than hashing. Encryption is not suitable for hashing passwords, because encrypted things can be decrypted.
If it is possible to retrieve the original password from whatever value you have in the DB, you have failed.
In this sense, md5 is closer to the right answer (it's still not the right answer), because it is a hashing function, and not encryption.
Yes, but don't take this approach. Use password_hash() and friends, which do the right thing automatically and without any action needed on your part.
It is definitely best practice, yes. But not salting passwords is not acceptable. The point of salting is to slow brute force attacks on stolen hashes — since every salt is unique, every hash is unique (even those that were computed from the same raw password), and so every hash must be attacked individually.
+1111
Agreed. I shouldn't have omitted this point. I usually recommend closer to .5s (but i'm weird).
1 Like