I am using PHP 5.6 on Apache 2.4

I have a form that will collect sensitive information about the user that need to be encrypted. My current solution grabs the sensitive information from the POST and immediately one way asymmetrically encrypt it with a public key before storing it the database. I will be using SSL on the site.

My plan is to retrieve the encrypted version and decrypt locally as the information is needed, and when the data isn't needed further, I am going to delete it entirely.

I am worried that if the server is compromised and a hacker is capable of knowing that the above is going on, there is an opportunity for the hacker to write a script to collect the POST data before I can process and empty it.

I have looked into encrypting the information before the form submits via JavaScript, but I am concerned about CPU / memory load it would cause on the browser.

Are there any better ways to make sure at no point can someone, via an injected script, access the POST data? Or am I just being extra paranoid?


I am encrypting the sensitive information with RSA 16,384 bit public / private keys. The average size of the information block is closer to 8000 bits, but the 16,384 bit allows for extreme use cases.

Only the public key is on the server, I process the information into a JSON array and then use PHP's openssl_public_encrypt() function. I then store the encrypted block in MySQL.

When decrypting the information for use, I download the encrypted block via a secure admin portal (HTTPS, CSRF token, recycled one way hash password comparison) and decrypt using a JavaScript based library on my local machine.

This is my worst case scenario

Prior to this project, I would have agreed with the sentiment that if a hacker is on my system, then I have bigger problems. However, a hacker sniffing this information prior to the encryption is exactly the biggest problem I have. It's not CC#s, I am handling that via Stripe and 100% PCI Compliant.

However, I would have equal, if not greater, liability if this information was compromised.

That is why I am going to such extremes as handling decryption locally. I have read the PCI compliance basics, such that sensitive information needs to be encrypted in transit and in storage, but there seems to be a gap during processing even there. If I am wrong there, please point out documentation, so I can better educate myself.

  • If your server is fully compromised, you can't avoid the data being stolen anyway. Where do you store your encryption key? Is it on the same server in order to decrypt the data? Yes, you seem extra paranoid, but I see that as a good thing! What kind of "sensitive data" are you storing anyway? Perhaps the PCI guidelines can help you?
    – Jeroen
    Commented Oct 20, 2015 at 5:49
  • Can you tell more how do you manage the keys?
    – user45139
    Commented Oct 20, 2015 at 6:45

2 Answers 2


Do not use new solution, reuse what others have gone though. A good place to start is OWASP.

For the transport, use SSL and do not manage some kind of encryption on the browser instead.

Once data lands on your server, assess whether to store it encrypted and what risk exactly you want to avoid by encrypting them. This will drive the encryption architecture (physical theft prevention? Admin access prevention? ...).

And then, the absolutely key is to make sure your application is coded correctly. The OWASP link above will point you to generic cases and specific implementation solutions (for PHP for instance)


If you followed safety methods to set the forms (PHP Security Guide: Form Processing) and you have done, in addition, what you stated above (public cryptography + HTTPS) that's already good.

But as for:

I am worried that if the server is compromised and a hacker is capable of knowing that the above is going on, there is an opportunity for the hacker to write a script to collect the POST data before I can process and empty it.

If you reached the situation where your server is compromised then you will have more serious things to worry about than just what to do to prevent the attacker from gathering the POST data.

I suggest you to say how you manage the (encryption) key(s) in terms of where you store it/them and whether or not you use the same key to decrypt for all users or do you use one key per user (though I think you work with the first option), after that, I will edit this answer. It is better to have I am paranoiad attitude than the I don't care one.

  • I've updated the original post with the requested info. Thanks! Commented Oct 20, 2015 at 22:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .