Imagine a table in a database in MySQL that holds millions of telephone and cellphone numbers that relate to itemized billing for VoIP and Cellular carriers.
All of these numbers are in VARCHAR fields and they are clearly visible to anyone who has access to the database. These numbers need to be like this because they are read out to form parts of reports and because there are millions of records, it's quite resource intensive to sift through it all.
I'm in search of ways to store these numbers in a way that would be well… Safer.
Say for instance, the database got compromised and someone else gained access to this information… They would have millions of active numbers and could really make havoc out of that.
So to avoid this situation (it's not physically possible at the moment as we're on a closed network) in the future, what would be the right thing to do with all of these numbers?
I need a way to make then like a hash and then unhash them on request… The problem is the resources involved in this, any one number could have thousands of records so this would end up being quite resource intensive… There must be a more suitable solution for something like this?
I'd like to say that I am really looking for some opinions, feedback, input or guidance from some professionals with relative experience. I'm sure that in the manual there is something somewhere that covers something sort of like this… But I cannot seem to find it so I would like some insight into how to deal with this the correct way!
Thank you.
EDIT: I'd like to note that this question is not about server security, it is about information security… When i look at the database and see raw numbers it just feels wrong… Is it wrong or am i just being paranoid?
Best Answer
If you store encrypted data in the database, the data is not understandable anymore without a layer of code on top. This might seem like a good move, but if one takes a closer look, it complicates things and does not provide more security.
An example which becomes a lot more complicated: "Compute the number of phone numbers with a special area code". How to do this in a normal DB? Well something like
SELECT COUNT(*) FROM phonenumbers WHERE phonenumber LIKE "XZY%"will work. How to do this, if the database cannot understand its own data? Transfer everything to the application, decrypt it and compute the result there. That can obviously be really cumbersome with large databases. Basically all advantages one receives through using a DBMS are nullified.Why this is not more secure? One does not even have to hack your database anymore, it is enough to hack the application. Likely this is easier, since the application uses a lot of custom code. Further the firewall will allow access to the application servers, while it will likely prohibit access to database servers from outside.
What to do instead? Secure the database server and restrict access to sensitive data. You can (should) create a dedicated area for sensitive data, which can only be accessed with dedicated database accounts. This credentials should be used rarely in your application, and should not be handed over easily to e.g. developers. You could even set up an own dedicated isolated database server for such sensitive information.