This password database resides on the authentication server which is connected to the Internet.

My question is that if the password database is stored on different server than the machine connected to the Internet, will it prevent database breach?

The machine connected to the network can load the data from the password database using the local network as and when needed.

In this case, what scenarios do not prevent the breach?


No, it would not add anything other than security by obscurity which is not a great thing, it'll give you delusions of strong security.

Depending on what level of access the person gets to the network facing server, it's still trivial to get to the database. not to mention, what is probably the majority of the time, breaches happen by SQL injection which would still cause issues here as the network-facing server would just act as a proxy for the specially crafted user submitted data and the return from the server. if the attacker was to gain, for instance, shell access to the network-facing computer, they could just manually connect to the database server on the local network and wreak havoc.

| improve this answer | |
  • yes, SQL injection attacks are not prevented by storing the password database offline. – Curious Sep 29 '14 at 12:08
  • and, as pointed out, the only benefit of this setup is security by obscurity. an attacker would have to read your code or what ever to find where the database is; from there's it's pretty trivial. you're better off securing your internet-facing server with firewalls and keeping software up to date. – miethpo Sep 29 '14 at 12:10
  • @miethpo I object to your comment about it not adding security, because moving your database off your web server is a good security practice. This architecture may not prevent SQL injection, but it might prevent a database breach if SQL injection is not a vulnerability. While an attacker might still be able to gain access to the database server from the web server this requires more work on their part, which might be prevented by other security controls or detected before too much damage is caused. – PwdRsch Sep 29 '14 at 15:16
  • @PwdRsch as I said, at best security by obscurity. it may take them a little more time to get to your database but you're still wide open. all you are doing is making slowing them down and people tend to gain the delusion that this actually makes them in general secure, for this reason it's not advisable to move the database to another server just for security purposes. it's good for other purposes, but not this. – miethpo Sep 30 '14 at 12:39
  • That's not security by obscurity, that is layered defenses which are a cornerstone of information security. Learn the difference. – PwdRsch Sep 30 '14 at 14:37

Its actually typical to have a database behind an internal firewall that only your semi-trusted applications and specific internal networks can access.

It doesn't prevent a breach, but I think I understand what you would like to achieve, and that is access restriction by what is accessing the database.

If you stored your passwords in their own schema (pass.passwords instead of dbo.passwords), you could restrict access to the pass schema to whatever you would like.

Technically applications don't necessarily need to access the tables where passwords are stored, but they do need the salts, which aren't a secret anyways. So that you could store the salts in your dbo.user table, but the actual password in pass.passwords table.

You could give your applications access to stored procs, one of which could be dbo.Authenticate(userId, hash), and restrict access to the pass schema to an offline internal network and restricted to specific users.

And I don't think access restriction is considered obfuscation.

| improve this answer | |

Your Answer

