Best practices for using pgcrypto PGP encryption with Heroku and Rails

Question

Are there any security best practices for using Rails and Heroku Postgres with pgcrypto's public key PGP.

The naive and direct way seems to be to store the private key and password using Heroku's ENV variables. However this seems like it doesn't add much security since both values are now easily accessed by anyone with access to the environment.

The goal of this would be to encrypt any privacy concerned information such as SIN numbers appropriately.

Scenario:

Let's presume you have some fields that, for some generic regulatory privacy requirement, are required or recommended to be stored encrypted, such as government IDs (SIN numbers for example). What is an appropriate or even common process for encrypting this information using pgcrypto.

If someone has an alternative suggestion for a scenario I'd be glad to include that as well.

Answer 1

This question doesn't have an answer until you define your threat model, but your question suggests that you want to store information in a way that even people with access to the server environment can't read it, in which case there are really only these options:

1. Don't store the data at all. Depending on what you need the data for you may be able to avoid storing it on your own servers for any reason. For instance, you can ask a user to enter their credit card number and immediately forward it to the credit card processor without saving it (which means you will need to ask them for the number again next time, unless the credit card processor hangs on to it for you.) Some payment processing schemes even send the payment data directly to the processor so that your website doesn't have to touch that data at all. Depending on your requirements this may or may not suit your needs.

2. Store the data only as a hash, like a password. This is useful if you don't actually need the data, but only need to verify that someone using your site has the data. This is universally the solution for passwords and other "secrets" but is useless for other data.

3. Store the data with public/private encryption, and don't keep the private key on the server at all. This could work if, for instance, the server has the public key in its environment, with which it saves data to the table, but an administrator has to download the encrypted data and decrypt it locally in order to use it. Again, this has severe limitations so you can only use it if your requirements of what to do with the data are compatible.

4. Store the data with client-side symmetric encryption, encrypted and decrypted only with a client key. This is how e.g. LastPass works. It means that you, the server admin, can not do anything with the data except return it to the user that submitted it. Once again, this only works if your requirements are very narrow.

If your requirements for what you do with the data are not compatible with any of the above, then you have no recourse. You could encrypt the data with symmetric encryption and keep the key in the server environment as a guard against backups or access to the database, but not the application, falling into the wrong hands, but that does not match the threat model of an attacker with access to the operating environment.

There is no one-size-fits-all "best practice" here because the tradeoffs involved in handling a threat model where the attacker has access to the environment are so great that only applications with very specific, limited requirements can guard against it at all. If the server can read the data, then so can an attacker.