3 ms·

Some clarification. Sensitive data will be things like full names addresses passport photos credit card details etc Encryption. I'm thinking public key might w

• bigiain 11y ago
  You can't. Not against even a marginally skilled attacker. If the server contains what it needs to decrypt the data, any attacker who p0wns your server can extract that. If you only need protection against skript kiddies running automated attacks - look at how Apache/OpenSSL deal with passphrase protected private keys. They go to some length to ensure the decrypted private key only ever exists in-memory, and doesn't get written to disk, but someone who's escalated to local root can (I'm pretty sure) grab the key out of ram (core dumping the whole process, if need be). If you _have_ to have sensitive data stored and available to the server - consider storing the sensitive/encrypted data on a separate system with a much smaller attack surface than a publicly available web server (assuming that's what we're talking about here), with a extremely tightly specified API that's small and well defined enough to make it practical to come much closer to fully auditing the code - and where it's practical to monitor the API for intrusion or unexpected requests and shut it down pre-emptively before you lose your whole database. Mostly though, I advise working out a way to not have to do that. (Note that "storing credit card details" immediately confers the whole responsibility of PCI compliance on you. It is, in my experience, almost _never_ worthwhile doing that - leave that headache to Stripe/Square/Paypal/whoever, and re think your business process to suit.)