An article on Habré about password hashing. Some points are unclear. Can you help me figure it out?

Question

Information Security

Hello. I deal with this article here:
https://habr.com/post/210760/
After reading, several questions arose.
1) When hashing a password, do I need to take a random salt? And when checking, do a loop - hash the password being checked through all the salts from the database and check if the hash matches the one in the database, right?
3) How many salts should there be in the database?
4) If I randomly choose a salt from the database, can it still turn out that users with the same password will have the same password hash? after all, chance can fall on the same salt. Is it normal?
5) Can this method be used to create a password / token (to recover the password / verify the mailbox)? Or does it make the site vulnerable? It seems like a stupid question, but in the same article on Habré it says this:

I will immediately determine what task of using hashes I will consider - user authentication. Not password recovery tokens, not request authentication, not anything else. This is also not an article about data link security, so the challenge-response and SSL comments are out of place!

Answer 1

Have answered many times already . I advise you to read carefully. Also, on the same Habré, there are more recent sane articles: About storing passwords in a database (be sure to read the comments) Correct answers on cryptography: 2018 Directly on your questions: 1. When creating a password hash, generate a random salt. Store the hash + salt in the database. When checking a password, choose a hash + salt from the database, hash the resulting password with a salt, and compare the result with the hash from the database. 3. Each stored password hash has its own unique salt. 4. Salt is generated quite randomly because it
should be difficult to guess . This means that the entropy for this case is taken quite large, and you don’t have to worry about the fact that, purely theoretically, you can generate 2 identical salts. The probability of such a case is approximately comparable to the probability that all the air molecules in your room will take and gather in one corner, that is, it is extremely small (s). And even if you spend the entire supply of luck in your life on such a truly unique case, then nothing terrible and irreparable will happen - well, the attacker will understand that these 2 users have the same password, well, that's all - the passwords are still need to be hacked.
5. Yes, you can. Although the task of hashing passwords and the task of restoring access by token are 2 different tasks, with different given and goals, but the first task is part of the second, because you need to store the fingerprint of the user's secret in the database (which is a temporary recovery token). The algorithm is simple: generate a random temporary recovery token -> write its fingerprint (hash + salt) and lifetime to the database -> send the token to the user -> the user follows the link with the token -> check the validity of the token by its fingerprint and lifetime -> force user to enter a new password. In fact, a recovery token is a one-time temporary password that provides access to set a permanent password.
Well, the traditional advice: use the recommended algorithms (Argon2, Bcrypt, scrypt, etc.) to obtain fingerprints of user secrets, and not your own implementations. Everything is done there under the hood as it should, because there are also enough nuances in this matter (time cost, memory cost, constant time comparisons, etc.).

Answer 2

1. No. The salt can be stored next to the hash in the table
. You can use the same salt for all passwords, but very long
. If not enough, you can attach an immutable user account parameter such as creation date to the salt
3. Either all or none
4. The salt is not random. The salt (or part of the salt) is unambiguously bound to the user's record 5. It's easier to use the user 's
UUID + email link with storing the UUID in the user's record and checking it take on faith