This question already has an answer here:
- Does anybody not store salts? 9 answers
(This is not a duplicated of the linked question IMHO as this is more about the differences between a salt and password: both variables used to generate a hash)
Let's say an attacker has offline access to a database in which passwords are hashed with bcrypt (no pepper added). The hashes look like:
In which the salt is:
H0mRpD2XJZDguAzxTehwzu and the hash is
The attacker will be unable to run a rainbow table to match hashes, but she could compute common passwords using the salt included, so executing:
bcrypt("abcd1234", 10, "H0mRpD2XJZDguAzxTehwzu")
And there you have! She could go through all the database testing "abcd1234" and be able to identify which users are using that weak password in a matter of seconds/minutes.
So what if only the hash
nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G is stored at the database (no salt)?
If the attacker has a strong feeling that the user "abcdefg" might be using the password "abcd1234", how could she test her theory offline? She would need to guess the salt. How could she do it? Is there any easier method than trying each combination? Maybe in that specific case there won't be enough motivation to try it. But what if she suspects the system is using the same salt for all passwords (as some hashes are the same)? How hard it would be for her to crack it?
Peleus's answer is close to what I was expecting. I will try to extend it (correct me if I'm wrong):
In Bcrypt a salt is usually of 16 random bytes (128 bits). If we compare that to a password of the same length, then a salt will have a grater entropy than a password, as passwords are usually limited to what the user can type with a keyboard.
Those 16 bytes are encoded into HEX (using Base64) and become 22 of length. If we compare them with a 22-chars password, then the password will contain a greater entropy (as it can include symbols and the full alphabet).
Bcrypt salts are limited to 16 bytes while passwords may be limited to 72 bytes, depending on implementation.
2 different salts will generate 2 different hashes, and so the passwords. However at some point 2 different salts could produce the same hash using the same password and vice-versa. Which is the probability for each of those cases? That is something maybe I should ask in crypto.SE. But I leave it here in case someone has the answer to it.
The algorithm was designed to protect passwords and not salts. This means that salts are not mean to be safe by design, which suggests that there could potentially be a way to obtain them without brute-forcing them.
We are used to the user-password method to protect access to a system. But, what if something like this happens (please bare with me, its just an example)?:
CauseWeWantItThatWay use microchips to store a unique 22-hex-chars value (to be used as salt). Each user will generate a total of 5 passwords or PIN numbers (4 digits each, yes, they are lazy) with that unique salt to access 5 different systems.
Now let's assume I'm assigned to one of those systems and I know one of those PIN numbers, and somehow I have access to the database. If the salt were included, it would be trivial to get those PIN numbers, however without the salt, I would have to crack it.
I know what you are thinking. The company has a really bad security implementation (and they should burn in hell). Also, that they could have used the "salt" as pepper instead, and leave the salt random. So my question was, in that case, it would be the same to add a 22-hex-chars as pepper than using those as salt? According to Peleus, is the same (so no shortcuts exists to get the salt).
After all not everyone follows the recommendations and the algorithm allows you to set the salt, which makes this kind of scenario totally possible (although not so probable nor recommended).