0

Currently we are creating one small service, where we are using some sensitive data from users(not worth zillions but to me it is like password). The idea is that application itself only inserts this data into db and creates some jobs to run in queue.

The problem is how to secure this sensitive data?

Currently the only good solution which I see is:

Encrypt and hash this data on application server. So in db we have hash for verification/comparison, encrypted encryption key and encrypted data. Encryption key in encrypted with public key.

On queue worker server we have private key, which allows us decrypt and process data.

Why I see this working. 1. In case of sql injection only encrypted data is compromised. 2. In case application machine is compromised there is still no private key to decrypt data. 3. Queue worker server is quite isolated and sits under firewall. So private key is somehow safe.

Does this sounds like a plan?

Jevgeni Smirnov
  • 101
  • 1

1 Answers1

1

What is your threat model? Always answer that first.

It looks like existing data is probably safe (given most reasonable threat models). However, you are as strong as your weakest link. The front-facing servers still have to hold onto the data during processing. Does your threat model include a hacker that compromises that server and simply begins siphoning off sensitive data as it is entered by users?

Cort Ammon
  • 9,206
  • 3
  • 25
  • 26
  • Honestly I don't have any :shy:. Well in general it seems that in case hacker will be able to modify source code(I am using PHP) there is a slight chance that he will be able to get data. But I have a couple of counter-measures in mind against getting access to server/shell/remote execution. – Jevgeni Smirnov Jan 07 '15 at 12:53
  • I still think that having the data of many other users laying around ready for the grab by the hacker is worst than just those connecting now. If that data is not saved in the database and retrievable that way, that is. – Alexis Wilke Apr 11 '16 at 22:24