2

Suppose we have web and application servers and trying to encrypt credit card information for our financial web application. Communication between web and app servers are secured through SSL/TLS. Lets say encrypted data is needed in the web server which will be sent to the application server to be secured. Is there a difference between these two approaches:

  • Getting the encryption key from application server (which obtains the key from HSM) and encrypting data in the web server.
  • Sending non-encrypted data to the application server which encrypts data using the key obtained from HSM and returns it back to the web server.

Details about the environment

We are trying to achieve PCI-DSS certificate for our virtual POS application. Web server is open to internet outside communication is also secure (SSL). Application server contains the business logic and only accessed by the web server. You can assume that all other security criterias for PCI-DSS is ensured.

  • Not an an answer to your question, but: Why are you trying to encrypt user passwords? Shouldn't you hash them instead? – Anders May 18 '16 at 7:38
  • @Anders Yes you are right, I gave it just as an example. Let's say credit card data instead. – berkersonmez May 18 '16 at 7:44
2

There is a reason for encrypting the data where its stored - that being the storage may be compromised (directly or from a backup copy). If we agree that maintaining the data in an encrypted form is a good idea, then access to the decryption key must be restricted.

You didn't specify if the encryption was symmetric or asymmetric. In the case of the former, the decryption key is the encryption key.

Taking the case of the asymmetric key, there is a risk that someone with access to the data, could use your infrastructure as means for finding collisions and hence brute forcing the data - but this would be very small.

Similarly, doing the encryption on the client means that you are exposing the algorithm - leaving aside the arguments about Kerchoff's principle vs. security by obscurity, this extends the attack surface at the client. Again the risk is very small.

If the (server-side) application has no visibility of the unencrypted data nor the decryption key, then compromise of the application does not compromise the data - but its hard to imagine why you would be capturing and storing data you can't do anything useful with.

  • We are using symmetric encryption. In this case I understand that you are saying that exposing the key into the client carries more risk. Thanks for your answer. – berkersonmez May 18 '16 at 19:22
1

Since the communication between web and app servers are secured through SSL/TLS, the data's already being encrypted in transit by the session key - so I think your two options are very similar.

There might be a slight advantage for encrypting for the application server's HSM key right off the bat so that the data's plaintext is never on the application server - but if you're worried about compromise of the application server, then you have bigger problems.

Lastly, I don't know anything about PCI-DSS, but from Wikipedia:

  1. Protect stored cardholder data
  2. Encrypt transmission of cardholder data across open, public networks

Either variant of your scheme would seem to meet both of those.

  • Thanks for your answer. You are saying that doing encryption on the application server means exposing the plaintext data into the app server. I don't understand how exposing the encryption key in the web server is less of a risk than carrying plaintext data into the server. Am I wrong to think that encryption key is more sensitive data than encrypted data where carrying it all the way from HSM to web server is very risky? – berkersonmez May 18 '16 at 19:10
  • I made the assumption that you're doing asymmetric (aka public key) encryption where the decryption key is the only one you need to protect - the encryption key is public. If you mean symmetric encryption like AES, then yeah, that's dumb, don't let that key leave the HSM. – Mike Ounsworth May 18 '16 at 19:13

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.