Password Security: Encrypting salt

Question

Possible Duplicate:
Password Hashing add salt + pepper or is salt enough?

I'm new to security and trying to understand why encrypting or hiding a salt is not considered useful. I've read the earlier post https://stackoverflow.com/questions/213380/the-necessity-of-hiding-the-salt-for-a-hash on why hiding or encrypting salt is unnecessary but the answer was based off the assumption

If someone has access to your database, then they have access to the encrypted salts, and they probably have access to your code as well

Question

Just because an attacker has access to your database why should we assume he has access to the code interacting with it? For example, you have your salted passwords on a MySQL server on one machine along with the encrypted salts. And you have the key for decrypting the salts or some intricate encryption/decryption logic on a web server on a separate machine. An attacker gains access to the database via SQL injection or some other means. Hasn't the encryption and distributed architecture saved the day here?

Answer 1

You'll hear different arguments here but, at the end of the day, it comes down to how your system works in the real world.

It is certainly possible to build a system in which compromise of the database tier does not yield compromise of the application tier. You could imagine hardening against things like:

• Injection of arbitrary data from the db layer does not cause a security issue in the front end (ie it assumes it will get back bad data)
• Physical access of the db tier does not imply physical access of the application tier.
• Infrastructure services (admin creds, share services for things like patch management, etc.) are isolated such that there is no way to island hop across.
• The ability to push code to the db tier does not imply the ability to push code to the app tier.

...and so on.

So yes, it could be done. Pragmatically, very few apps work this way. I have seen very few in my career that could honestly say they have achieved this.

IMO, this is why people tend to not see this as super valuable, as very few apps are able to make this sort of security claim.

Answer 2

Encrypting salts is not very useful as you would need to store the key somewhere. Most of the time the key (or the access to the key) can be retrieved from code. In general, each time you think up a protocol using encryption you need to specify how the keys are accessed. If you don't have a direct answer to that, you're probably in for a redesign.

Instead you could make up the salt out of a secret stored in the code, and a purely random part stored in the data base. As there is no size limit to a salt you can simply concatenate the parts together to make the full salt. This can be useful as the attacker now has to gain access to the code as well. Of course, the code should then not be available to the attacker. The reason why this is not deployed much is that most of the time access to the database equals access to the code.

Answer 3

If the attacker finds the passwords (and salts) using an SQL injection vulnerability, he only has access to the information the database has access to. In this case it doesn't matter if the code is on the same machine as the database, since the database itself usually cannot access the code that connects to it.

The situation is different when the attacker has gained access to the machine that runs the database, in this case he will probably be able to access both the database and the code (if the code is on the same machine).

So if the web server and the database run on separate machines, and the attacker only has access through an SQL injection vulnerability, he would indeed have very a hard time cracking those passwords.