5

Possible Duplicate:
Password Hashing add salt + pepper or is salt enough?
Any risk in using the same salt for several hashes on a user?

It's known that all password hashes need to be salted, but a debate often arises which salting strategy to use:

  • One common salt, hard-coded in the application away from the data
  • One salt per one hash, stored in the database next to the hash, never reused

How do these two approaches compare against different attacks or leaks? Is one more secure than the other?

Community
  • 1
Kos
  • 1,478
  • 1
  • 9
  • 11
  • 1
    Possible duplicate: [Any risk in using the same salt for several hashes on a user?](http://security.stackexchange.com/q/6251/5501) – Andrei Botalov Aug 08 '12 at 08:43

1 Answers1

7

There is tons already written on this site about salting. Please go read that, and then come back if you have further questions. Don't miss Password Hashing add salt + pepper or is salt enough?.

TL;DR: Each user should receive their own individual random salt, stored in the database, next to the hash. You could optionally also include a second application-wide salt ("pepper") stored elsewhere, but it's not critical.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 1
    So the two approaches I've mentioned are actually referred to as pepper and salt, respectively, and the first should only be used as a supplement to the other. – Kos Aug 08 '12 at 09:27
  • @D.W. Can you elaborate on "next to the hash"? I have seen suggestions to store the per-user hash in a separate column as well as the same column as the password. If stored in the same column how do you determine where the salt ends and the pass begins? Have people experimented with mixing them up together in some way to further obfuscate? or is that completely unnecessary? Thanks! – Matthew Sanders Apr 14 '19 at 18:00
  • @MatthewSanders, either is fine, it doesn't matter. You can use any convenient way to represent or encode those pair of values; it's not security-critical. Mixing them up and obfuscation is unnecessary and unlikely to help much. Instead of obfuscation, use a pepper (but don't store it in the database). Make sure to read the link in my answer. – D.W. Apr 14 '19 at 19:58
  • Thanks @D.W. I read through the link you gave and have a better understanding from some other searching as well. I've also been using bcrypt.js in node but didn't fully understand the inner workings. Looks like the answer to my question is that the salt will be a fixed length and thus you can easy append and retrieve it after concatenation. – Matthew Sanders Apr 14 '19 at 20:07
  • I am not sure if I missed that, but actually in this accepted answer, as well as in other linked thread there isn't clear explanation why the salt per password is better than global salt. I am personally using random salt per each password entry, however would like to understand what are the downsides of global salt. – NeverEndingQueue Mar 04 '21 at 17:38
  • @NeverEndingQueue, global salt is definitely bad. If you want to understand why, I suggest asking a new question, and sharing your current understanding in that question. – D.W. Mar 04 '21 at 23:09
  • @D.W. We would then end up with another duplicate thread. I took time to understand the implications. So what's the difference? Global salt (aka pepper) is not sufficient alone, however can be used on top of salt and shall be stored outside DB, ideally injected from outside (not stored in codebase). Pepper, used alone without salt, allows attacker to see which users have same password set. Compromise of just one hash/password in that same password group reveals password of other users. If salt is dynamic for each password than hash is different even if same password is used, preventing this. – NeverEndingQueue Mar 05 '21 at 08:43
  • @NeverEndingQueue, you're right. The problems with global salt are already explained at https://security.stackexchange.com/q/6251/971. I encourage you to avoid using the word "global salt" as a synonym pepper; that sounds confusing to me. I interpreted "global salt" to mean that instead of a salt that is unique per password, you use the same salt value for all passwords. Or perhaps you mean that you use only a pepper and no salt? If so, the problem with that is again covered at https://security.stackexchange.com/q/6251/971, if the pepper becomes known to the attacker. – D.W. Mar 05 '21 at 09:28
  • Thanks for the hint, I will stop using: "global salt" then, however in my comment I've used the terms in relation to this topic, which is old, but it still stands, quoting: `Global salt` `One common salt, hard-coded in the application away from the data` I agree that it's not safe to call global salt a pepper, I've did it presuming that there wouldn't be any point to keep the same piece of string (static salt) in the database, it would likely end up being in code or configuration, effectively becoming a pepper. – NeverEndingQueue Mar 05 '21 at 19:17