Ask HN: Securely store sensitive data in the DB?

Passwords are kept hashed, so the password provided in the login gets hashed and if it matches the stored hashed password the user is authenticated, otherwise not. The password is not stored in cleartext and cannot be retrieved, but of course can be reset if the user forgets it. So far so good but what happens with other sensitive data that I need store, as API keys, cc data etc? These cannot be encrypted with the user password, because if the user forgets the password these become useless.

What are some best practises to keep sensitive data encrypted on the database, and reassuring that after a system break-in the attackers won't be able to get the data unencrypted? I want to design and implement a solution as secure as it can be and would like to hear thoughts, ideas and experience by other startups and engineers. I have not found anything really useful in this direction, apart from references to proprietary solutions that promise to do anything on some magical way (no comments!)

If you have compliance reasons motivating this need for encryption, you'll find that e.g. HIPAA and PCI-DSS ignore technical reality, in favor of requiring that you encrypt information stored at rest and imposing substantial penalties on you if it leaks. There are a variety of ways to do this. One fairly common one for HIPAA-compliant applications is putting the e.g. MySQL data files on a partition which is block-level encrypted. You then issue decryption keys to folks who need them, such as e.g. the application.

If your host is totally compromised, the host holds both the decryption key and the ciphertext, which means "Sucks to be you." However, this does provide non-zero increase in security (e.g. if an old copy of the DB drive ends up floating off to eBay because of poor physical control on your part, and you can document that it doesn't include the encryption key, you just avoided a reportable information breach), and it does check the appropriate boxes on e.g. HIPAA.

So your question is actually: How can I make my system divulge the least amount of data as possible over time to someone who has compromised the service?

To hamper someone from changing your service to remove security you could set up daily checks from a server hosted in a different location to download your static resources and check them against a pre-validated hash.

For storing data - as others have mentioned - the key is to store that data in a way that it cannot be accessed from that one server alone. A simple solution for this is to setup an internal service that will provide the data when given the correct login details. This gives the attacker an additional server he would need to hack. If you keep this layer as simple as possible it can add a lot of security. Of coarse, if the hacker is able to compromise your server for a long period, he can record anything passing through here anyway.

In the end though, the web-server itself is a lynchpin in which all customer data has to flow at some point, and if that key server is compromised for a long enough period, eventually all data can be extracted regardless of precautions. That means that designing your web service with security in mind from day 1 is very important. Regardless of what people try to sell you here, there are no silver bullets that will prevent data theft - only mitigate the impact or delay it.

If they root your web tier, and your web tier knows how to ask your internal service layer for sensitive data, then the attacker knows how to ask your internal service layer for sensitive data.

I really hate repeating "If you lose any one box in your deployment then you can assume you will lose all data, regardless of whether you encrypt things or not" because it makes me feel like Debbie Downer, but that is, in fact, the threat environment.