I'm trying to figure out a decent encryption strategy for a small business application. My main goal is to expose myself to as little unencrypted PI as possible.
I have no idea if I'm overthinking this and there's an easy way, so I thought I'd ask. I'd also like to hear if any of my thoughts are complete rubbish.
I've thought of 2 strategies thus far:
When a user logs in, they're asked to input a master decryption password. This password is used to decrypt the private key and a random string is generated & stored in a cookie (or perhaps in local storage + transmitted with every post request). The private key is re-encrypted with the random string and whenever encrypted data is requested the cookie string is used to decrypt the key, then the data.
Disadvantage: As the server admin/hacker, I could obviously intercept the master password and decrypt the key, then the data.
Advantage: Pretty straight forward.
The public key only is stored on the server. Between the server and the client is a reverse proxy which parses the content (similar to how ESI work). This proxy server would contain the private key and decrypt the data before serving to the client. The keys on this server wouldn't be managed by the same admin.
- Disadvantage: As the proxy admin/hacker you could obviously intercept the data as it goes through. You would also have private key access.
- Advantage: As the proxy admin/hacker you wouldn't have credentials to the application, thus you would only be able to sniff data that is requested by the end users.
- Advantage: In a business environment, it's likely that this server can be much more easily protected against external sources. No incoming connections could be allowed at all.
The following are treated as a given:
- All transport is secured by SSL.
- In all scenarios I would have access to data as it was input. This could be mitigated by using JS public key encryption.
- Actual application authentication is fit for purpose. I.E. Social engineering, brute force etc are all discounted. Browser-based issues/bugs are not discounted.
- The encrypted data needs to be accessible by a team of authorised people.
- It needs to be accessed through a browser.
- The whole disk is encrypted at rest, which is no benefit to, say, breaching root via SSH.
I've discounted the following:
- JS decryption—from what I've seen, this just means the private key is exposed to the end user.
- Symmetric keys & pub/priv keys unencrypted on server, DB on another server. I'm not really sure of the value of these. As an Admin, or a hacker, I would have everything I need to decrypt the MySQL data if I were to breach the application server.
- Third party Key servers: This just seems to pass the buck to someone else being able to see the content (though I am wondering if there's a multi-step process that could work in conjunction).