@morbiuswilters said:
Understandable, but it's still probably mistaken. Guess what, at some point you have to trust people. If I have physical access to the hardware I can find ways to get sensitive data off of the system and manipulate records. There are methods to combat this but encrypting an internal network isn't one of them.
Sure you have to trust people, but sensible security means only entrusting people with the minimum access they need to do their job. Why would a company let just anyone have physical access to hardware? It's relatively cheap and easy to lock your hardware away from most staff. By doing so you've massively reduced your attack surface because 99% of your staff can't physically access the systems. Then your password hashing just has to stand up to the few who do have access.
The company where I used to work seem to have an extra layer that I call 'Security by Incompentence': all hardware access was done by a team of electrical engineers with no understanding of software. They wouldn't dare pressing F1 during a reboot unless a developer was on the phone talking them through how to do it.
By the way, with regard to
@morbiuswilters said:
For one, how were salts being stored on the webservers? Were you running databases on these machines?
This was an enterprise app, so the answer is obvious: store the salts in XML!
Actually it seems a reasonable solution to me. The hashing is done in the business layer code on the application servers, so the salts (only a few hundred, not one per password) are stored locally in XML for quick lookup. So it's (very) slightly less database traffic than storing the salts in the databases, and the DBAs never have access to the salts.