I am building a web application that will deal with highly sensitive data. My thought on improving security is to create one database for login information, and a completely separate database that contains the sensitive data. Authentication for the secure database will rely on two part authentication through the login database, and validation of the user’s account in the sensitive database.
My question is: are there any better solutions out there? Is there a major security flaw if I maintain both of these databases on a single server? Is it more worthwhile to maintain a single database but just encrypt the contents of the secure database? Is it overkill to both encrypt the contents of the secure database and have separately authenticated access to it via a different user/pass in the config file?
Hope this makes sense. Thanks.
It depends on the most likely attack vectors for your web application. If SQL Injection is a risk for your app, having separate databases won’t help if a user can log-in legitimately then spoof your app into reading other records in the table they already have access to.
One approach is to encrypt each record using a unique encryption key per user. That way if they did compromise one user account, the other rows will be gibberish. This is very slow, but if the information is that sensitive, you might have to live with that.
The other approach is to not make the sensitive information directly queryable by the web-app. You have your web app & non-sensitive database running in a DMZ, and your sensitive database running behind a firewall separating it from the DMZ. You then use a web service or tightly limited database role to get the data as needed. Then on your web service/database side, you make sure the code can only deliver the records the logged in user is allowed to see.