1

As stated in the title, how do I secure mysql against data tempering? I have been searching the internet for a solution but did not find one that fills my needs.

Let me describe my problem, assume I have sensitive information in a table, and a hacker can easily alter the data if he have the access to my database.

I know there are some solutions where you can hash the values and use checksums, but that can also be regenerated and manipulated by the hacker.

Even encrypting the data won't be enough, because that means that the key must be on the server which can be accessed by the hacker.

Now assume the hacker has access to my cpanel account, server (source code) and database, how can I make sure that the data is not tempered with?

I want to ensure the integrity of my data regardless if a hacker is a random person with limit access or a insider with alot of access.

Is it maybe possible to do something so solid like blockchain with mysql?

Joe
  • 2,734
  • 2
  • 12
  • 22
pabloBar
  • 35
  • 4
  • 2
    Can you elaborate on the use case of the database and what threats you expect? A database where users need to add information regularly is very different from one that only stores usernames and passwords. One that holds tables designed for secrets and tables designed for information or customization will have different threat models. There are a lot of things you can do, coming up with a good solution involves all of the pieces of the puzzle not just how the data itself is stored. – Nalaurien Jul 09 '17 at 10:24
  • 1
    To add to Nalaurien's questions: Data in databases is meant to be changed. What would be the technical difference between a legitimate change and "tampering" in your use-case? – Philipp Jul 09 '17 at 10:41
  • 1
    The use case of the database is to hold ecommerce related information, such as emails and passawords, along with transaction detalis. Now my initial thoughts are to have two tables, users and transactions. Where the transactions table will have records of transactions, info like user1 sold item1 to user2 for X amount. while users table will have email field, password field and account balance field. Now its as simple as changing the account balance field and manipulating the transaction log to make the account balance look legit. – pabloBar Jul 09 '17 at 10:57
  • so a legitimate change is when the application does based on a transaction, while the tampering is when the hacker goes into my database and starts changing data. – pabloBar Jul 09 '17 at 10:58
  • @pabloBar: so if the hacker hijacks your application to change data in the database it is valid while if the hacker directly connects to the database and changes data it is not? Sounds like you need proper authentication for your database then which allows only the application to connect. Or what apart from authentication distinguishes changes done by the application from changes outside the application? If you have some magic oracle which can tell proper changes from improper changes you should put it in front of the database. – Steffen Ullrich Jul 09 '17 at 15:26
  • yeah hijacking the application is an interesting scenario, and that i cant recognize a legit transaction from a fake is what scares me. Not sure what to do about it. not sure either how the banks handles such problems. Like if i now hack my bank and change my account balance to $10 M. How can they prove that its not a legit value ? – pabloBar Jul 09 '17 at 15:59

1 Answers1

0

In general, you can't be absolutely sure that there have been no changes to your data, especially if you're looking at the scenarios where an attacker has access to your application code. In that case, they can probably do anything which your application does, and you can't tell if they have once they are done.

However, if you work on securing access to your systems, and monitor any unexpected access to them, you can get a pretty good idea if something has changed.

For example, if only your application server can connect to your database server, with a limited privilege user, you can immediately reduce the risk of someone being able to edit the database contents - if they got the code in some way which didn't involve compromising the application server (perhaps from an old backup file), they'd still need to compromise the application server to be able to do anything to your data.

You can also implement things like offline auditing - store each day's audit logs on a read only system, as well as on the database system, and compare them on a regular basis. If someone can compromise both copies, you've probably got bigger problems.

Going to even more extensive levels, you can have devices which allow very limited access to data, and all access is logged. Banking systems sometimes take this approach, but it's probably too expensive to implement for any but the largest e-commerce sites.

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • Fair enough, i guess that i have to be realistic and accept the fact that you can do much when the application is compromised. I will configurate so only application can connect to mysql server, encrypt data in the database using AES, send a signature with each transaction(an encryption of userid+sellerid+timestamp using AES). as long as the application is not compromised then it should be impossible to forge the transaction log. The offline auditing sound interesting, could elaborate more on how its done? or link me to some reading materials ? – pabloBar Jul 10 '17 at 21:14