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!

Belthian
  • 59
  • 3
  • 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 '15 at 08: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 '15 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 '15 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 '15 at 14:29
  • @AviD your description was vague enough to be correct, it was his his redescription that was not – Richie Frame Feb 24 '15 at 21:04

1 Answers1

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.

Community
  • 1
M'vy
  • 13,053
  • 3
  • 48
  • 69
  • 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 '15 at 08: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 '15 at 09:37
  • You are assuming the same basic order. What if I decide `salt1 + password + salt2`? That changes the game... – Ismael Miguel Feb 24 '15 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 '15 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 '15 at 14:18
  • It does make a difference because of the fact that both salts are stored seperately. Only one of the salts is stored in the database, whereas the other is stored in the web application code (which is compiled). For an attacker to try and create a rainbow table they'd first have to compromise both of those. The salt that is stored in the web application binary would be generated at compilation time. – Belthian Feb 24 '15 at 17:19
  • @Belthian. I think you're misunderstanding what salt is for. The point of salt is that you can give the salt to the attacker and they still can't easily crack the encryption. It doesn't matter where you store the salt since you are giving it up willingly. – TTT Feb 24 '15 at 19:52