

Ask HN: What are best practices for encrypting sensitive user data on a server? - teapot01


======
bigiain
The timeworn advice is: "TLS for data on the fly, GPG for data at rest". With
suitably updated TLS/SSL libraries and configurations, and good GPG keys, this
is still sound advice.

The big question in my mind is always "Does the server need to be able to
decrypt that data?" If the server has the decryption keys, the attacker can
probably steal them along with the encrypted data. I store GPG encrypted data
on servers where they only have the public key - retrieving the data involves
grabbing the encrypted data from the server and decrypting it somewhere else
that has the private key available. (This is a handy trick for web forms that
collect sensitive data - serialise it and GPG encrypt it immediately, then you
can happily send the encrypted blob via non-100%-reliable email,and have the
local encrypted blob available if the email copy fails to arrive.)

------
dutchbrit
Define sensitive user data and how do you want to store it? In a file or in a
database? AES-256 is pretty good for encryption but you also need to handle
decryption somehow - and you don't really want to store passphrases on a
server. Passphrases can be encrypted using pgp if you want multiple users to
have access to the passphrase. When it comes to password hashing (not
encryption), then go with bcrypt or scrypt.

But please define sensitive data more in detail. Are we talking about
passwords, messages or photos of passports etc?

~~~
teapot01
Some clarification. Sensitive data will be things like full names addresses
passport photos credit card details etc

Encryption. I'm thinking public key might work, but if I want to decrypt on
the server how do I keep private keys private?

~~~
bigiain
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.)

------
teapot01
What I'm interested in is how should I encrypt and store sensitive user data
on a server such that it is retrievable but secure.

~~~
DanBC
Secure from what?

Secure from remote but unskilled attackers using auto tools poorly?

Secure from remote but skilled users targetting your system?

Local and skilled users targetting your system?

Law enforcement smashing the door down?

Well formed legal documents?

Well funded government agencies?

Malicious employees?

~~~
teapot01
Ultimately I think the main danger is a skilled attacker targeting the system.
That said I would like to secure data from a local attacker as well.
Ultimately I understand that it will be difficult to secure fully against
someone with hardware access but any risk mitigation practices I could use?

