Storing salt in code instead of database

Question

There have been a couple of great discussions regarding salt best practices, and it seems the overwhelming recommendation is to generate a different salt for each password and store it alongside the password in the database.

However, if I understand the purpose of salt correctly, it is to reduce the chance that you will be compromised by rainbow table attacks. So, I understand that by storing it in the database it would be optimal to change it for each user, but what if the salt is nowhere near the database? If I store a single salt value in the code (which would on the web server be in a compiled dll), wouldn't that serve the same purpose if an attacker were to somehow gain access to the database? It would seem to me to be more secure.

Answer 1

... until the attacker gains access to the DLL.

Answer 2

The value of a salt lies in it being different for each user. You also need to be able to retrieve this non-unique value when you're re-creating the hashed value for comparison purposes.

If you store a single salt value that you use for every password, then you massively reduce the value of having a salt in the first place.

Answer 3

The purpose of a salt is to require the regeneration of a rainbow table per password. If you use a single salt, the hacker/cracker only has to regenerate the rainbow table once and he has all your passwords. But if you generate a random one per user, he has to generate one per user. Much more expensive on the hackers part. This is why you can store a salt in plain text, it doesn't matter if the hacker knows it as long as there's more than one.

Security by obscurity is not good, microsoft has taught us that.

Answer 4

The lesson I learned from salts is: Divide and Conquer (security)

Answer 5

In addition to other answers, it's also worth noting that an attacker could figure out your salt in the same way he would figure out a password: Given a known password (his own), he can do a brute force attack on possible salts.