Does the salt from the password hash make sense?

Question

PHP

I read a bunch of articles about the proper storage and encryption of passwords.
Of all the existing ones, the most “popular” is storing the password in the database in the form md5 (md5 (password) + salt), while the salt is stored in the database in the next column (well, or in the same column where the hash is).
This method of course complicates password cracking, but having a hash and a salt is still possible to crack.
Does it make sense if
1. we hash the password: hash1 = md5(password)
2. we take 10 characters from hash1 as a salt
3. we get the final hash using the old algorithm: md5(md5(password)+salt), or
md5( md5(password)+substr(md5(password),0,10) )

Question: will this method be better than the salt in a separate column, or worse? Maybe there is something more "cunningly perverted"?

Answer 1

Yes, of course this way is better.
What you are suggesting is called dynamic salt.
If you really want something “cunningly twisted”, then you can store something like this in the database:
substr(md5(md5 (<динамическая соль> . $password) . <статическая соль>), 0, 16);
where the dynamic salt will be calculated like this, for example:
substr($login, 0, 3) . ($password, 1, 5) . $login[4] .$password[0] . <статическая соль>

Answer 2

there have already been so many articles on this topic on Habré that it’s even embarrassing to answer.

Answer 3

In general, there is a fairly standard solution: use HMAC. It was specifically designed for hashing with salt. Naturally, the salt must be generated randomly and stored next to the hash.

Answer 4

Usually like ... salt for each user is different. Usually this is a random string. When hashing a password with a salt, greater crypto protection is achieved by increasing the brute force time to get the desired password + salt string.
And you can make it even cooler - you can use slow algorithms. Tobish, let's say hashing happens in a loop. If the number of iterations is dynamic, then this is good. And encryption algorithms should not be taken as fast md5, but something slower, for example sha512. This, in turn, will reduce attempts to select a hash and generate rainbow tables to naught, because each brute force option will be unthinkably slow. On a good video card with CUDA, you can generate a million MD5 hashes per second. And it’s so good if it generates a hundred.

Answer 5

md5 is no longer relevant, use bcrypt and don't rack your brains.

Answer 6

What is salt for anyway? And in order for md5(password)+salt to be long enough so that it cannot be obtained from the hash using precomputed tables. The table will give something, but there is no guarantee that your salt will be at the end.
In my opinion, the cryptographic strength is the same: the same level of resistance to enumeration and the same protection against tables.

Answer 7

I am not strong in cryptography, but as far as I remember, salt was used not only as a way to increase the password string, but also the strength of the hash. But also as a secure method of transferring data from the browser to the server. Look at the ready-made forums, engines, etc., why is everyone storing salts in the database, and not writing algorithms for dynamic salts?
Let's say you write a forum, you decide to use a dynamic salt algorithm, ala

substr(md5(md5 (<динамическая соль> . $password) . <статическая соль>), 0, 16);

The weakness of this method is that the attacker knows in advance your hash algorithm, and hence the salt. Having received the same cookie with a hash (which is obviously easier than having a database), he will not have any difficulties in guessing the password, because. he is aware of how this hash is obtained.
Another thing is if the salt is dynamic + stored on the server in the database. Having received a cookie with a password hash, it will not be possible to recover the password from it, because even the owner of this hash does not know his salt, only the server knows about it.

Answer 8

If everything is ok with English, then I advise you to read RFC 2898

Answer 9

One of the most important goals of salting passwords is to prevent identical hashes in the event of a password match.
If you don't want a separate column, keep the salt in the same column as a fixed length prefix. Better yet, sell the bike and take crypt() - it can do both salt and bcrypt, and everything is stored in one column

Answer 10

Well, as you know, one of the weak points of md5 is the presence of collisions. That is, simply two different pieces of text can set the same hash. Therefore, salting md5, with modern computing power, is not very effective. You can also brute with the help of hash tables. And a bunch of online services have been providing their services for several years. MD5 has recently been used more for checksum verification, and as mentioned above, see bcrypt.