2

This question already has an answer here:

After reading some posts and articles about how to store user credentials in a database, in which all said that we should use a different salt for each user and save the salt in the database along with the hashing of password + salt, I still have one question.

Is it secure to store the salt along with the hashed password in the database? Please correct me if I'm wrong but if I get access to the database and see what the salt was for that password, I can create a rainbow table with that salt, no? I'm trying to understand how secure is too store the salt not how to store the salt.

marked as duplicate by Xander, Matthew, Steffen Ullrich, schroeder Nov 28 '16 at 17:43

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Im trying to understand how secure is too store the salt not how to store the salt. Thank you – André Morais Nov 28 '16 at 17:18
  • 4
    The titles are different, but the questions and answers are the same. – Xander Nov 28 '16 at 17:19
  • too => to by the way – Bryan Field Nov 28 '16 at 17:39
5

but if i get access to the database and see what salt was used to that password i can create a rainbow table with that salt no

Yes you can, but it would only work that one password. The whole point of rainbow tables is that you can compute one once and reuse it again and again. The per-password salt means that each password hash must be attacked individually.

So to answer the question, no, the salt is not a secret.

  • But if a create e rainbow table to the admin account? – André Morais Nov 28 '16 at 17:53
  • 1
    Creating the rainbow table for a single password takes more time and much more space than just directly guessing in brute-force fashion. The point of a rainbow table is to create one rainbow table to use in guessing all the passwords in a database. There's no point in computing a new rainbow table to guess one password. The point of salt is to force the attacker to guess one password at a time rather than being able to check the whole database with a single table. There's no reason to keep the salt secret to accomplish that. – Ben Nov 29 '16 at 15:42
1

After reading some posts and articles about how to store user credentials in database, in which all said that we should use a different salt to each user and save in the database the salt and the hashing of password + salt

Correct.

Salt is unique for each user.

It can also be helpful to add Pepper, which is not unique, but is stored outside the database, either in the application code, or a separate file.

i stay with one question. Is secure to store the salt along with the hashed password in the database?

Yes.

Please correct me if I'm wrong but if i get access to the database and see what salt was used to that password i can create a rainbow table with that salt no?

Yes, but salt is unique per person. Creating a rainbow table for one person is not helpful.

  • But if a create a rainbow table to the admin account? That would be useful no? – André Morais Nov 28 '16 at 17:52
  • The attacker would just crack the password without using a rainbow table. Creating a rainbow table first would require extra work and storage space. – Bryan Field Nov 28 '16 at 18:01
  • For extra security add Pepper, so the attacker would need to find the Pepper first before starting to crack. – Bryan Field Nov 28 '16 at 18:01
  • 2
    @AndréMorais When a proper salt is used, a rainbow table is never an efficient tool. If you had the password hash and salt for an admin account you could certainly try to crack them, but you would not pre-compute a rainbow table to do it. – Xander Nov 28 '16 at 18:06

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