It's a good security scheme save user data in different MySQL tables?

I'm programming a sensitive application (health data) that requires a good security schema. Of course, bugs exists and hackers or user may found it. So my concern is to protect data as much as I can. Reading something about security I have found a mechanism that could be useful, but I would like to listen the opinion of someone more experienced in this stuff. The scheme is:

• Create a database, call it 'app' for example
• Create some common tables (or not)
• For eac开发者_StackOverflow中文版h user, create a set of tables with a prefix based on the user name and a hash to avoid a user to known other user prefix (sjiXoi4sa_table)
• All database queries for a user will put his own prefix except those refered to the global scope

Is this a good security scheme? Could it be improved? (for instance, it will be great if each user may encrypt their own tables). Any suggestion welcome.

---

As you describe it, the schema does nothing to improve security - OTOH, the additional overhead in working with more tables means more code means more defects injected. You are also compromising performance with this approach.

However if you were to set up the permissions so that a user only had read/write access to their own tables, then yes, it would be more secure - however you've still caused yourself a lot of problems elsewhere. You can get the same level of security AND reduce the complexity / amount of code AND solve the performance / scalability problems by normalising the data properly, and denying all access by users to the tables - but grant access via stored procedures (where you can effectively apply permissions on a row-by-row basis).

---

This is security by obscurity, and doesn't add any protection. If the site is hacked, the hacker will just dump the mysql database, not just the user table

---

This will do nothing to address the security issues in your application and will have the added disadvantage of impacting on performance (creation of tables, indices etc). Consider encrypting data instead and locking down access to user specific data based on which user is logged into your system.

---

In addition to everyone else's answer to why your schema is a bad idea, here's another piece of advice: Your dealing with health data, so there are probably regulations that you must follow to ensure security. For example, NIST standards or whatever your national equivalent is. Find them, read them, follow them. In many jurisdictions around the world such standards are mandatory, and you could be liable for damages if something happens and you didn't follow the standards.

So, find out what (if any) standards apply to processing and storing private health data in your country, and use them.

---

Any scheme that requires the creation of a new set of tables for every new record in another table is too horrible to use except in obfuscation contests, no matter how much security it adds. And as already pointed out, it doesn't add much security either.