1

We are behind in ensuring compliance to the new GDPR that has just come in to effect and I am currently looking at encrypting the data stored in our database for our ecommerce website. I realise that encryption is not mandatory, but nether the less I think it would be a useful added security.

My question is: Are there any advantages/disadvantages to encrypting the entire database at rest, as well as storing values using my own encryption? Is this something you would do, or would you consider just one of these methods to be enough to provide good security for personal data?

My theory is that encrypting the values as they are stored and retrieved using our PHP scripts will protect us if anyone somehow gets a hold of our database back ups - and that the table encryption will protect us should someone gain access to the database itself.

I have been looking into this: Innodb Tablespace Encryption

This should serve to encrypt the entire database table(s). I would then look to manually encrypt any personal data sent to the database using PHP's openssl_encrypt function.

Any advice here would be appreciated. Many thanks in advance!

TPHughes
  • 1,437
  • 11
  • 13
  • 2
    I don't currently have time to anwer this properly but: Just "encrypting" because you can is rarely worth the time and cost overheads unless you already know what you're doing. You need to build a **threat model**. What are you encryptin against? What are the likely areas of compromise? And then work to fix those rather than just blanked human-obfuscation of data. – Martin May 29 '18 at 08:31
  • 1
    NOTE: If you're "*behind in ensuring compliance to the new GDPR*" Then it is totally unwise and unefficient to then be doing extra unnessecary stuff as "*I realise that encryption is not mandatory,*". Get on with fixing your GDPR and not adding extra workload. – Martin May 29 '18 at 08:35
  • I appreciate your thoughts Martin and I agree, I will be looking at doing this very last when everything else is completed and in place. But I wanted to put this question up to gain some insight before we begin. – TPHughes May 29 '18 at 08:38

1 Answers1

1

I think a good rule of thumb here is to encrypt personally identifiable information that you know you aren't going to need to perform a search on at a later date. This maintains a balance between usability for your service and the effort to keep your users information safe.

For example, the UserID and their email would be silly to encrypt. The users first name, last name and physical address, however, would be good candidates. You're relatively unlikely to perform a lookup on this information.

Higher security information might require a more in-depth approach. For this, you can derive an encryption key from the users password and use that key to encrypt the information. This has the benefit that even if both your database server and your API server are compromised, the attacker cannot retrieve this information. The downside is that you need the user to enter their password anytime you need to use this information.

Luke Joshua Park
  • 9,527
  • 5
  • 27
  • 44
  • 1
    I would like to add that it is possible to search encrypted data but it requires extra tables of *hashed* data and then matching the hashes just as is done with passwords (`hashed not encrypted` `;-)` ). It's a hassle to setup, and is a big processor / data overhead but it can be done. Email addresses are also one of the most valuable entities in stolen data, too. – Martin May 29 '18 at 08:42
  • @Martin Yeah I've read about using similar methods in practice. Bit of a effort to setup but relatively effective. I stated in my answer it was silly to encrypt the email field because I assumed it would be tied to a user account and needed for login. Do you think it is worth using the hashing method you detailed for facilitating encryption of email addresses? – Luke Joshua Park May 29 '18 at 08:45
  • Oh, your answer is good, I don't want to be dissing your post -- but I wanted to simply clarify that searching encrypted data is possible with the use of hash tables -- but as I said the overhead is significant. – Martin May 29 '18 at 08:48
  • To answer your comment; it depends on who the encryption is defending against; but generally yes -- hashing email addresses is a very good idea as they're the gold target of many automated hacks. Therefore when someone logs in with email/password, both fields are hash compared or a third field is added to limit the target rows to check. (for example the domain of the email is preserved). Anyhow I should be working!! Enjoy yoursef `:-)` – Martin May 29 '18 at 08:49
  • @Martin Thanks for your opinion. I don't live in a country affected by the GDPR so I haven't spent the time I probably should have researching it. I expect similar legislation will come into effect here too so I've got to keep up to date! – Luke Joshua Park May 29 '18 at 08:51
  • Thank you both of you for your advice. It has been very useful. :) I will definitely look to hash the email address'. Have a good day and thanks again! – TPHughes May 29 '18 at 09:13