0

I am lookin to harden security on one of my client sites. There is no payment provider set up so sensitive Direct Debit information needs to be on a mySql server. This Direct Debit information needs to be human readable by users from accounting department.

Testing server is set up as follows:

  1. At present, main site is sitting on a wordpress blog.
  2. Customer completes HTTPS encrypted form with an EV SSL certificate.
  3. Data is stored in a separate database to the wordpress database.
  4. Direct debit details are currently stored as plain text

Now part 4 is what bothers me... but it's ok at the moment, because only on the testing server!

Gravy
  • 12,264
  • 26
  • 124
  • 193

2 Answers2

1

This is really difficult to answer, as it depends on how far you need to protect this data.

First step is obviously encrypting all details stored in mysql, incase someone gets a dump of your database.

This solution is good, but it introduces the vulnerability as if someone gets the decryption keys from your application server, they would be able to decrypt the dump of the database anyway.

There are many solutions to consider from here, i'm sure with some research you should be able to find some decent ones, but one way that comes to mind is:

You could encrypt the data on the application servers with a public/private key encryption algorithm. Public key can only be used to encrypt the information for storage, which lives on your application server. If that gets hacked, the only thing that they will be able to do is to add more data to your database =/. The private key in this case will be a password that would need to be entered every time a human needs to see this information.

This has the obvious disadvantage that you can't do any machine processing on your data, as its traveling completely encrypted all the way until its displayed.

(And you still have vulnerabilities of someone gaining access to your application server and simply dumping the session files/memcache where the key would have to be stored temporarily)

To be honest, first thing i'd do is encrypt the entire database one way or another. That alone adds a decent layer of protection. Dumping the database is easier than getting access to the file system of a server in most cases.

Yarek T
  • 9,715
  • 2
  • 28
  • 38
  • 1
    I think you hit the nail on the head indirectly - the direct debit database MUST NOT be read accessible from the web frontend under ANY circumstances. This is classic security isolation. – Yann Ramin Mar 04 '13 at 05:32
  • Good point, +1 for Security by Isolation. I don't tend to rely on isolation from the first step. Normally I hash whatever I can so I physically *don't* have the data, and if a reversible method is needed then encrypt and protect the keys instead. Its simpler to protect just the key rather than entire DB – Yarek T Mar 04 '13 at 16:45
0

Are you talking about bank account details / credit card details or both?

Be aware storing credit card details brings attached fulfilling PCI requirements.

Also, if you are planning to store confidential details, NEVER store them unencrypted.

Any questions, just let me know.

Fabio @fcerullo

fcerullo
  • 621
  • 4
  • 3