Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

In the app I'm writing I separated the user and main databases a long time ago for "security reasons". However its getting harder and harder to justify the overhead and the difficulty of managing such a setup.

For some quick detail this is a PHP web app. There are 2 separate mysqli connections, one for each database. Each database has its own user with its own credentials. This means you can't get to the main database with the user database credentials

In theory this prevents SQL injection damage, separation of concerns, security through obscurity, etc. However in a costs vs rewards I loose easy interoperability with the user table and the rest of the database, eg joins.

Are there more concrete reasons that such a database setup makes sense? Is this even common?

share|improve this question
4  
This is not "(in)security though obscurity", which is always a vulnerability. Its security though isolation, which is a defense in depth security measure. –  Rook Jan 2 '12 at 22:16
    
@Rook, please explain why "security though obscurity" is "always a vulnerability" –  George Bailey Jan 3 '12 at 20:04
    
@George Bailey To be honest in my carrier I have never heard of it being refereed to as a good idea, in fact if it actually worked then it wouldn't be called "security though obscurity", it would just be called security. wikipeida has a good discussion on this topic. –  Rook Jan 3 '12 at 20:09
add comment

2 Answers

Rather than two separate connections working together, you can use separate user accounts with access to specific columns. Most of your statements can use the user account that has access only to the username (not password) column of the users table, and the less important data from your main db.

In MySQL, you can do this with nice granularity. This will allow you to show everyone's usernames, and only access passwords in login pages, and only access sessions in session management, only access email addresses in notifiers, etc.

With this model, SQL Injections will generally be limited to the public info, or the single section that they reach.

Of course, what is public, how your users are set up, how many, what they get is all specific to your use case.

Check the GRANT documentation for your version of MySQL.

Disclaimer: This is not a fix to SQL Injection, only an effort to help minimize the impact.

share|improve this answer
    
This is... impressive. I had no idea I could do this. I will be sure to look into it. –  TheLQ Jan 2 '12 at 23:10
6  
@TheLQ You can also limit the risk of disclosure by never allowing the password hash to be read. Use stored procedures to create setHash() and verifyHash() functions to inform your application whether the password matches. –  Jeff Ferland Jan 5 '12 at 8:50
add comment

if the app accessing the two different DB is the same, the separation of the DBs is not so useful. It complicates EVERY programming phase and DATA related question. I'd prefer a logical separation instead of physical separation of the data.

It's the same with two safes: if you have the 2 keys in the same place, how much security is for the two safes?

The "usability vs security" balance here looses much more usability respect to security.

share|improve this answer
    
Please describe "logical separation". –  George Bailey Jan 9 '12 at 20:29
    
You don't have two different DBs but only one with different credentials and privileges to access different data. –  robob Jan 10 '12 at 6:02
    
My thoughts exactly. Just didn't know it by name. –  George Bailey Jan 10 '12 at 13:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.