1

I'm designing a database interface for a system that could store PII. My first focus is on making sure all the data is secure, to do this I have designed the system as follows.

I'm running three separate servers with three separate roles. Server 1, the web interface (Which I will refer to as El Jefe), takes requests from users and processes them, and returns the appropriate information as needed.

Server 2, the cryptographic interface (Which I will refer to as the Bagman) receives information via SSL from El Jefe and encrypts it (Using the Halite interface from Paragon Initiative Enterprises), then passes it on to server 3.

Server 3, the database (Which I will refer to as the Stash) stores the encrypted information it receives from the Bagman. It does not have the encryption keys from the Bagman or anything else like that.

Right now, the data at rest is secure. If the Stash somehow gets broken into, none of the files mean anything and none of the entries in the database mean anything because they're all encrypted, and none of the keys are stored on that server.

However, if the Bagman gets broken into, then all information that gets passed through him can be stolen.

Additionally, if El Jefe gets compromised, he can issue instructions to the Bagman to retrieve, decrypt, and return anything located in the Stash.

To mitigate against this I had the following plan: To minimize any damage from a breach of either El Jefe or of the Bagman I was going to salt the encryption key with a SHA2 hash of the user's password, so even if someone breaks into the Bagman, the keys are worthless without the additional hash of the user's password. However I feel like this falls into the realm of "Rolling your own crypto", which based off my readings for the past 2 weeks is a No-Go. Additionally, I would run into the issue of if a user forgets their password then there is no way to recover their files. Or if they decide to change their password I would have to decrypt, then re-encrypt all of their files.

I apologize for the corny names of the servers, by the way. It helps me remember their roles and visualize what they're doing in my mind. If you can point me in the direction of any resources or additional readings or whitepapers on designing a secure system like this, it would be much appreciated.

Will
  • 11
  • 2
  • Instead of user password, I would suggest adding a Hardware security module to the mix and use that for encryption and decryption operation or if that is a significant performance hit, store keys used for data encryption in HSM. – jhash Aug 21 '18 at 01:38
  • I'm using virtual hosting so while that would be a viable solution for people who own their own servers, I can't do it myself. – Will Aug 21 '18 at 07:03
  • Look at Key Management Solutions that provide REST API for operations. Most of these product work in hosted environment, virtual environment as VMs or containers and even SaaS version. – jhash Aug 22 '18 at 17:32

1 Answers1

1

SQLCipher is an option.

You need to use threat modelling to really secure your service as there are many ways apart from classic hacking, such as outlined in OWASP Top 10. Particularly SQL injection or CSRF that could also compromise the PII.

Encryption prevents someone from stealing the DBMS either logically or physically, it doesn't stop holes in your programming/implementation allowing someone to steal the data.

SeeYouInDisneyland
  • 1,428
  • 9
  • 20
user2505690
  • 72
  • 3
  • Yes, I'm going through the OWASP guidelines to prevent XSS and CSRF attacks against the service as well.I should be safe from SQL injection as I'm using prepared statements in all my queries (Or am I running on outdated information?) – Will Aug 20 '18 at 14:44
  • I fail to see how a transparent database encryption product is an option here. OP already encrypts what he's sending to the database, the question is about how to make it secure even if the web interface is breached (since it must be able to query and retrieve decrypted information from the database). – AndrolGenhald Aug 20 '18 at 18:24