1

I have read many and many of this type of question on the security stack community before I asked this question, but one thing that made me mad about salts and saving it in database is this ... I will put myself in the attacker's position.

If I hack into a database and find a table called for example ( users ) and I see a field named ( salt ) and another one ( password or hash ) I can easily - with no effort - know that the salt is used to produce this hash or this password. So I will take the salt of the first record for example and make a dictionary of all hashes of all English words ( rainbow table ) and then I'll use the salt that I got from the first record and try hashing it with each hash I got in the rainbow table and I will get the salted hash easily at the end ........ so please why do all people say on SO or the Internet say that putting the salt in the database is good practice or safe? .. I don't see it as safe and please correct me if I am wrong .. thanks in advance.

I have postponed my project because of this issue.

Azeezah M
  • 53
  • 4
ahmed nader
  • 121
  • 1
  • 5
  • Salts don't help if the attackers are targeting one individual account, but they greatly increase the effort necessary if the attacker wants to crack as many passwords as possible (which is usually the case). The salt prevents a hash table calculated from efforts to crack one account from being useful in cracking any of the other accounts. – tlng05 Jun 24 '16 at 20:01
  • so you mean that i cant prevent signle accounts getting hacked ? even when i add salt ? – ahmed nader Jun 24 '16 at 20:02
  • 1
    @ahmednader: There is no **absolute** security, so all you can do is to make it harder to crack. – Julie Pelletier Jun 24 '16 at 20:04
  • yes Indeed but i mean salt prevent generating huge amount of passwords of many users but cant save single users if they are choosed to be hacked right ? – ahmed nader Jun 24 '16 at 20:05
  • That is correct; the salt will be ineffective if the attackers are only interested in one account. The best you can do in that case is to use a slow hash algorithm (bcrypt or PBKDF2 with many iterations) and hope the user chose a strong password. (However, I'd add that it is quite rare to steal an entire database with only one account in mind.) – tlng05 Jun 24 '16 at 20:07
  • Many rounds of computationally expensive calculations protect against targeted attacks – Neil Smithline Jun 24 '16 at 20:11
  • what about putting my salt with the hash and get it out to be used when i need ? can the attacker figure it out ? it will be distributed within the hash – ahmed nader Jun 24 '16 at 20:23

4 Answers4

4

The purpose of salting is, that one cannot build a rainbow table to get several passwords at once.

Without salting: An attacker could search the internet for precalculated rainbow-tables and find the passwords with no effort.

With a constant salt: The attacker has to build one rainbow-table for this specific salt, and can then get all the passwords with this single rainbow-table.

With a unique salt: If each password get its own salt, the attacker has to build a rainbow-table for each password. In this case brute-forcing is faster, it doesn't make sense to finish the rainbow-table after finding a match, because you cannot get other passwords anyway.

So you see, even if the salt is known it fulfills its purpose. If you want to add a secret to the process, you should instead use a server side key and encrypt the already calculated password hashes. Do not mix up salting with other security measures.

martinstoeckli
  • 5,149
  • 2
  • 27
  • 32
  • can i use 2 salts 1 unique in database for each user and 1 constant in the php code that are away fro the attacker ? and does this prevent him from getting the password ? – ahmed nader Jun 24 '16 at 20:11
  • @ahmednader No, because if your database is compromised, it is highly likely your PHP source code is compromised as well. The attacker would simply look at the PHP source to find the second salt. – tlng05 Jun 24 '16 at 20:15
  • @ahmednader - There is no advantage in using two salts, or actually we could say that your second salt (the one in the PHP code) is not a salt at all, it is called a pepper. A better way to reach the same goal is, to use the second salt as a key, to encrypt the password hash. I tried to explain this at the end of my [tutorial](http://www.martinstoeckli.ch/hash/en/index.php) about secure password storing, together with the pros and cons. – martinstoeckli Jun 24 '16 at 20:16
  • what about putting my salt with the hash and get it out to be used when i need ? can the attacker figure it out ? it will be distributed within the hash – ahmed nader Jun 24 '16 at 20:24
  • @ahmednader - Yes this is the usual way to store the hash, a lot of hashing functions like BCrypt combine all parameters like the algorithm, the salt and the cost factor into one string. This string can then be stored in a single field in the database. – martinstoeckli Jun 24 '16 at 20:26
  • ok can i know which hash function i use ? i know there are some that were reported as having collisions like md5 or weak like sha1 – ahmed nader Jun 24 '16 at 20:28
  • 1
    @ahmednader - Of course, you need an algorithm with a cost factor, recommended are BCrypt, PBKDF2, SCrypt and the youngest Argon2. Not recommended, because they are too fast, are MD5 and the SHA-* family. – martinstoeckli Jun 24 '16 at 20:31
  • @martinstoeckli thank you very much, allot of things are obvious now – ahmed nader Jun 24 '16 at 20:33
0

You answered your question, just did not saw it.

why all people say on SO or Internet anyway that putting the salt in the database is good practice or safe

The answer is:

if I hack to a database (...) I will take the salt of the first record for example and make a dictionary of all hashes of all english words ( rainbow table ) and then I make another step which is using the salt that I got from the first record and try hashing it with each hash I got in the rainbow table and I will get the salted hash easily at the end

A non-salted hash will already have rainbow tables available. If you use salt, you will need to build it. The only thing where you are wrong is when you say that it is easy. It is not easy, at all, because you will need a new "rainbow table" for the salted hash. It takes a lot of computer power and time, and that is the protection you are adding.

Note: a salted hash is not re-hashing the password hash with a salt. Is more like mixing (or concatenating) the original password and the salt and then hashing it.

CristianTM
  • 2,532
  • 15
  • 20
  • so you mean that i am right .. but it is just a way of making it harder and more time consuming on the attacker ? – ahmed nader Jun 24 '16 at 20:07
  • 1
    Yes, it is there mainly to avoid that an attacker can use precomputer rainbow tables, and needs to brute-force it by himself (ex build his own "rainbo table" specific to one hash+salt, that technically is more like a brute force attack than a rainbow table attack). – CristianTM Jun 24 '16 at 20:09
  • or can i hide the salt in the hash and get it out when i check for password ? – ahmed nader Jun 24 '16 at 20:14
  • Im not sure what you mean with 'hide' and recovery on hash. Hash is not reversible. You could mask it on the hash data (stenography) But that is more like security by obscurity. To protect on targeted attacks use PBKDF2 with many rounds to make brute force infeasible – CristianTM Jun 24 '16 at 20:23
  • i mean if the hash is abcdefg and the salt is 12345 i can concatenate them in a way the application only know it . abc123defg45 for example – ahmed nader Jun 24 '16 at 20:25
  • Yes you can. Many actually do it to avoid needing a new column on db. But is not hard to find it. An smart atracker will find it. – CristianTM Jun 24 '16 at 20:34
0

Others have clarified the purpose of Salt, which is to require a separate brute-force process per-user to crack, which would take much longer than a single brute-force process finding matches for every user at once. Salt is not needed to be secret, just unique.

A good way to improve on this is to include Pepper, which is secret. Pepper is just some random string for your application, either stored in the source code, or a separate file, but not in the SQL database.

The secret Pepper is combined with the Salt before generating the Hash. This way if the attacker uses SQL Injection (accessing Hash+Salt) and is not able to breach your filesystem (where the Pepper is stored), he will not be able to crack.

And of course there are ways to limit the impact of SQL Injection as well.

700 Software
  • 13,807
  • 3
  • 52
  • 82
0

The salt has to be stored someplace that's easily accessible given a user ID. That means a database table. The hacker who can get the hashed passwords can get the salts in the same way, often using SQL injection. As others have already written, the salt stops precomputation attacks.

There is an approach called a keyed hash in which the hash is generated from a concatenation of the plaintext password, the salt (still stored in the database and unique per-user) and a secret key. The key need not and should not be stored in the database. It could be stored in the filesystem or compiled into the login program. That provides a defense against SQL injection. However, as others have already written, there is no absolute security. If the attacker can compromise the server's operating system or the login application, then the key is compromised and your security is toast. (But precomputation attacks are still prevented by the salt, even for the attacker who has access to the key.)

Bob Brown
  • 5,283
  • 1
  • 19
  • 28