4

Is it a good idea to use two salts? This is implying that one would be unique to the user, and one would be unique to the server, using Bcrypt of course.

So for example, if you're using Golang as your backend, would it be a good idea to generate a 20 character long salt from /dev/random, bake it into the Golang binary, and use it with 20 character long salts generated from /dev/urandom that are unique to each user? The hashing process would look like userSalt + serverSalt + password = password digest

The idea behind this is that even if an attacker gains access to your database, they still wouldn't be able to crack passwords because they would also need to decompile your server to get the serverSalt. Even if they got the serverSalt, they would then need to generate rainbow tables, which would take a long time due to Bcrypt.

Thank you in advance!

Improve this question
5
  • Thank you, I didn't know that a second salt is called a pepper, therefore I didn't find anything in my searches.
    – Belthian
    Feb 24, 2015 at 8:51
  • @Belthian a 2nd salt is NOT a pepper, rather a secret value that is not key material is called pepper
    – Richie Frame
    Feb 24, 2015 at 12:52
  • @RichieFrame a "pepper" is essentially a "server-wide salt". So in this case, it is exactly what he meant.
    – AviD ♦
    Feb 24, 2015 at 14:28
  • and yes, technically speaking it does not serve the same purpose as an actual salt, so while my explanation may be a misnomer, it is what the OP was asking.
    – AviD ♦
    Feb 24, 2015 at 14:29
  • @AviD your description was vague enough to be correct, it was his his redescription that was not
    – Richie Frame
    Feb 24, 2015 at 21:04

1 Answer 1

Reset to default
9

Salts are not meant to be private anyway. They are meant to avoid dictionary / rainbow tables attacks on your hashes (see Why are salted hashes more secure for password storage? for more details). 

hashed_pwd = hash_function(salt + password)

So using two salts serves the same purpose as using one salt.

hashed_pwd = hash_function(salt1 + salt2 + password)

If salt1 + salt2 == salt you get the first code back.

Improve this answer
7
  • Yes, this is true. But if you use two salts, one being stored in the database like normal, and the other being baked into your web application code; an attacker would need to compromise both said things before even thinking about the possibility of creating a rainbow table.
    – Belthian
    Feb 24, 2015 at 8:57
  • 1
    If you have to create the rainbow table, you are using brute-force anyway. So you don't care about salts anymore since you will try all the possibilities. The idea behind rainbow tables is "to come prepared", so you just have to match the hashes, salts just deny this possibility whether you have it hardcoded or in your DB.
    – M'vy
    Feb 24, 2015 at 9:37
  • You are assuming the same basic order. What if I decide salt1 + password + salt2? That changes the game...
    – Ismael Miguel
    Feb 24, 2015 at 12:19
  • No it does not change anything. Look at it this way: suppose I do own a dictionary of passwords (domain) and their corresponding hash through hash_function (range), if you use this function on your system, I can intercept a hash, lookup my tables and get the corresponding password because that hash is in my range. If you pre/ap-pend something to the passwords, it means you are working from a different domain to the hash function. Since my range = hash_function(domain), changing the domain voids all my computations (provided the hash function is a good one).
    – M'vy
    Feb 24, 2015 at 12:31
  • It doesnt make a difference. The point of the salt is to prevent bruteforce with rainbow tables. Having 2 salts doesnt make that more difficult, its still the same brute force. What is the difference between adding 2 salts and adding 1 longer salt? None.
    – Wjdavis5
    Feb 24, 2015 at 14:18

Not the answer you're looking for? Browse other questions tagged .