4 ms·
Every salt example I've run across until now used the same salt for every password in the database. Obviously I can disregard those examples! Thanks for bringi
by wtracy 14y ago
Every salt example I've run across until now used the same salt for every password in the database. Obviously I can disregard those examples!
Thanks for bringing this up--the concept of salt makes a lot more sense to me now.
- lhnn 14y agoYa, that's silly. A common and simple password setup is hash(username+password) or hash(private_account_attribute+password). Also, use bcrypt/scrypt/similar.
- varikin 14y agoI have heard of doing both, though I have not seen it yet in production. It gives the benefit of having to get the code and the database while also requiring dictionaries to be build per password.
- tedunangst 14y agoI think the considered opinion of "the people in the know" is that getting the code is just not that hard, and the global secret technique offers more illusory security than real security.
- deleted 14y ago[deleted]
- masklinn 14y ago> Ya, that's silly. Not exactly. Having a salt at all mitigates rainbow table attacks, having a unique salt per password also limits brute-force attacks (you can't brute-force the whole table trying out cleartexts with a given salt, you have to brute-force each password individually). Having a global unique salt is already better than no salt at all.
- mcherm 14y agoUsing the same salt for every password in the database protects against an attacker using a pre-computed dictionary ("rainbow tables" are something like this) to attack your stored hash values. Using (and storing) a separate salt for each password protects against that and ALSO protects against the attacker building a dictionary of common passwords with a certain salt and then using that dictionary to crack ALL the passwords in the database at once. So one-salt-per-user is clearly better, but one-salt-for-all is still better than no-salt-at-all.