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?

Improve this question
1

1 Answer 1

Reset to default
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.

Improve this answer
9
  • 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 8, 2012 at 9: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, 2019 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, 2019 at 19:58
  • 1
    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.
    – Tom Raganowicz
    Mar 4, 2021 at 17:38
  • 1
    @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.
    – Tom Raganowicz
    Mar 5, 2021 at 8:43

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