In Linux we have the salt just next to the password hash in the /etc/shadows file.

I always hear that salt value prevents hashed passwords from being cracked by brute force methods. But if somehow we get the shadow file we can inject the salt in the algorithm and still use a brute force method, right?

I'm not considering the time spent, just the general idea. I know that brute forcing a SHA256 or SHA512 hash will take forever.

  • I suggest you read this security.stackexchange.com/questions/211/…. It's much more in depth than your question, but it gives a great overview of password hashing functions including salts and peppers. Jun 9, 2015 at 8:30
  • 1
    TL;DR, salts ensure that all passwords are globally unique to force an attacker to break each individually, thus preventing any reuse of work. They are not intended, expected, or required to be kept secret. That said, don't hash your own passwords; use something like bcrypt. Jun 9, 2015 at 8:45
  • If you like pseudocode, please look at this excellent answer that shows plain hashing compared to hashing with unique salts. You will see the additional amount of effort needed clearly.
    – mucaho
    Jun 9, 2015 at 11:00

5 Answers 5


Hashing the password with a salt makes it much harder for an attacker to use a precomputed list of hashes (aka rainbow tables) to run the discovered hash against.

It will force him to compute the hashes again for any salted password hash he wants to crack.


Salt doesn't have to be secret. However, it MUST be unique for each password. Consider this : if all your passwords are hashed with the same salt, then an attacker who gets access to your database "only" has to compute H(pwd+salt) for each possible pwd value and he gets all your passwords. If the salt is unique however, the same operation will only get him ONE password, the one associated with the salt he just tried.


A salt does not make brute-forcing a single password any harder, as you correctly pointed out.

Without a salt, an attacker could build one single rainbow-table, and (s)he would get all passwords at once. With a salt, the attacker has to build a rainbow-table for exactly this salt, so he cannot reuse already existing rainbow-tables. When you use a different unique salt for each password, then an attacker would have to build a rainbow-table for each password. This does not make sense, after finding a match there is no advantage to finish this rainbow-table, brute-forcing is cheaper.

With a unique salt per password, one cannot use a precalculated rainbow-table to get several passwords at once.

This also answers the question, why the salt doesn't need to be secret. Algorithms like SHA-* are not appropriate to hash passwords, because they are too fast and therefore can be brute-forced too easily. Use them together with PBKDF2 or use Bcrypt/Scrypt, which offer a cost factor.


You're right. Salting really makes password hacking more difficult for non-trivial passwords, but if some users use common passwords, can still hack the password by brute force a few thousands times.

If the salt is public/stored together, like your case, it is just used to prevent pre-computed password hashes lookup, i.e. rainbow table.

Thus, if for similar algorithms in web applications, I would suggest may also prepend a constant application-specific secret key to the users' password, before hashing by the salted algorithm. Of course if your app secret key is leaked, then this security enhancement is vanished. Thus, I store that secret key in code to separate it from the password hashes database. (That is unachievable in Linux shadow file)

Further remark: the main point of adding the extra "secret key" (or pepper) is: even the hash of a simple password cannot be brute force just few thousand times to crack it (they are as hard as complicated passwords to brute force), given that the hacker only know the password hash, but not yet able to see the secret key in your code. (Meanwhile, it doesn't guard the online website password brute force attempts, it guard the offline attempt to crack the hash itself only)

  • 1
    A salt is always public (at least, as much as the hash value). We do not rely on a salt value being secret to protect our hashing function. The "application-specific secret key" you mention is known as a "pepper", it's merits are debatable at best. It may add some security where your DB is compromised, but not the web application. Jun 9, 2015 at 8:25
  • 1
    Thanks for introducing me the word "pepper". Didn't aware that term before. :) Jun 9, 2015 at 8:29
  • @Chris Murray Thanks for comment. Of course my "pepper" method is not perfect, but if both our database, and web application (two layers) is compromised, I wonder if there is any other economy & good solution that is near-perfect to makes hacker very difficult to recover passwords, even all our system is compromised?? One could be suggested if it exist. Jun 9, 2015 at 8:46
  • What I introduced is use salt & pepper together. I would listen any reason for downvote, please. Jun 9, 2015 at 8:50
  • there is no perfect solution, but read the question I linked to in the comment on the question. Thomas does a great job of outlining what best practice is and why. Wasn't my downvote, btw. Jun 9, 2015 at 8:51

It makes a dictionary attack a lot more difficult, if the salt is created in a smart way. For example, bcrypt uses a 128 bit salt.
A salt is usually generated randomly. If it was derived only from the password or the password hash, it would indeed not add much security. If it is generated in a way that cannot be predicted by the attacker, it significantly increases the search space - making the brute force attack require a lot more brute force.

Keep in mind that even in a brute force attack, an attacker will still try the predictable passwords (like "pa$$w0rd") first. Assuming an unpredictable 128 bit salt, the attacker now has to try up to 2^128 more possibilities to crack the hash for "pa$$w0rd"+salt. On average that will be half of 2^128 possibilities before the attacker succeeds, which is still 2^127 more possibilities.

  • 1
    A salt is non secret. The attacker has no need to guess the salt, as it's stored right along side the hash. The salt is only meant to protect against a precomputed list of hashes. Jun 9, 2015 at 8:20
  • 1
    @ChrisMurray Precomputation isn't needed. Brute force against a list of hashes will have a major advantage if they are unsalted regardless of any precomputation.
    – kasperd
    Jun 9, 2015 at 10:26
  • @kasperd, You mean that if two people have chosen the same password they will have the same hash without salting, right? And therefore cracking the first one will also give you access to the second one. This is still precomputation. You have precomputed the first one, thereby given you access to the second one. Jun 9, 2015 at 10:36
  • @ChrisMurray I didn't say the hash or salt were secret. Even when using a precomputed list, the salt increases the search space by 2^(length of salt in bits). Requiring considerably more resources from the attacker.
    – S.L. Barth
    Jun 9, 2015 at 10:41
  • @S.L.Barth Um, no it doesn't. The attacker knows the salt (unless it's secret). There is no entropy, because the attacker is not guessing at the salt. The attacker simply has to use the salt that you've given them. Jun 9, 2015 at 10:50

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