We have a Customer who wants his sensitive user-data stored with an encryption.

These are the basic requirements:

  • Sensitive user-data is stored in a database using encryption
  • A remote-attacker who has access to the webserver and/or database gains no access to the sensitive data
  • User who are logged in need to be able to access the data

We came up with the following Environment & Workflow


  • Server 1

    • Webserver which enforces HTTPS
    • Database with encrypted user-data
    • Has no access to Server 2 - only to a service
  • Server 2

    • Service with 2 way auth
    • Has access to the encrypted database on Server 1
    • Has encryption key for userdata in Database on Server 1


  1. User logs into website with username & password [Login part 1]
  2. Server 1 requests a token on Server 2
  3. Server 2 decrypts the mobile phone number from the userdata on Server 1 and sends an auth-code SMS
  4. User enters the auth-code from the SMS into the form [Login part 2]
  5. Server 1 requests the encryption key from Server 2 using the token and auth-code
  6. Server 1 stores the requested key in the user-session (PHP-Session, webserver user has no access) . Server 1 uses some of the web-users connection data (ip-address & user-agent string) to encrypt the key in the user-session

Is this a good enough solution to protect the sensitive data?

  • Sensible -> Sensitive ​ ? ​ ​ ​ ​ – user49075 May 26 '16 at 22:16
  • Yes, than you for pointing that typo out. – nick May 27 '16 at 8:07
  • This is intended to deal with a scenario where sever 1 has been compromised but assuming server 2 has not been? – rdans May 27 '16 at 13:41
  • If thats the case you will also want to make sure that when server 2 connects to the db on server 1 that that connection is encrypted – rdans May 27 '16 at 13:43
  • Having said that, I guess in theory anybody who has access to server 1 also has the resources needed to listen to the incoming connection from server 2 and decrypt it if necessary. Not sure how this would be done in practice but seems like it should be possible since the db software has the ability to do it. So basically the attacker should be able to intercept the incoming connection from server 2 and then read the encryption key. – rdans May 27 '16 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.