Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Securely store sensitive data in the DB?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Ask HN: Securely store sensitive data in the DB?

#31

Post by liquidcool »

orofino wrote: post #24
patio11 wrote: post #5

Any system which allows you to locally decrypt information, for the purpose of doing anything for the user, should be assumed to allow an attacker who roots the box to locally decrypt information. That's the unfortunate harsh technical reality. 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 in…

To expand on this a bit, absolute security for encryption just doesn't exist. If you wanted your data 100% secure, put it in a database, disconnect the DB from your network, put it in a locked room, guarded by biometric locks and security guards. Even in that scenario, the data is vulnerable, but why even bother discussing that point, as the data is worthless if you can't access it. With that reality in mind, I was r…

I'm in ecommerce as well and I've seen PCI/DSS auditors require vendors/hosts to rearchitect using an encryption/key management appliance. You wrote you built your own solution - are there no known, trusted open source alternatives? As you mention, the appliances are almost astronomically priced, so it seems like an area OSS (or a disruptive startup) would help.

Re: Ask HN: Securely store sensitive data in the DB?

#32

Post by rythie »

Here's an idea:

Use the user's password to decrypt a key, that then decrypts the data - which I know you can't do because of password resets...

So to deal with password resets, create another password which decrypts the same key. Store that other password in a physical safe, possibly in a bank safety deposit box. This will slow down password resets to a manual process of course.

For additional security you can store these split a password in two or more pieces and store in different banks. For convenience you could allow users from the same organisation to reset each other's passwords (since they all have access to the same key).

Also, use a IDS so you know know as soon as you've been hacked - because people logging in at that time are still at risk.

Re: Ask HN: Securely store sensitive data in the DB?

#33

Post by raverbashing »

ra wrote: post #12
raverbashing wrote: post #2

- Keep passwords in memory (so as if you start the service it prompts for the password) - Asymmetrical crypto. So for example, you encrypt your CC data upon sign-up but then to run the charges you need the private key (and this is somewhere else) - Enable SSL communication with your DB. Postgres has this, because being defeated by network sniffing is bad.

Memory is not secure. It's quite a common attack to grab keys / passwords from the memory of an executing program.

No, it is one of the safest places.

If your attacker has access to arbitrary memory of a process, you're using an insecure OS/version. Or they dumped your process memory using a vulnerability (in your system)

Yes, there are some possible attacks (page file, cache, etc)

Attacking memory after a reboot requires physical access (unless you hibernated without an encrypted file, in this case...)

It certainly beats the security of file/network

Re: Ask HN: Securely store sensitive data in the DB?

#34

Post by EGreg »

Let's say you are able to perfectly encrypt something so that only the people who have "authorized access" can get the data.

You still have a problem of determining who these people are. See http://en.wikipedia.org/wiki/Confused_deputy_problem

Your best bet is to have three-factor authentication (something they are, something they have, something they know) generate a key to encrypt the data. Then their user agent still has to be trustworthy (no viruses on their computer, etc.) In addition it has to not be tricked by various exploits (such as https://www.owasp.org/index.php/Session_fixation, https://www.owasp.org/index.php/Session_hijacking_attack, http://en.wikipedia.org/wiki/Cross-site_request_forgery, https://en.wikipedia.org/wiki/Cross-site_scripting). You also have to secure the channel, preferably with TLS using Diffie-Hellman Key Exchange or some other way that won't be compromised just by stealing keys on the server. Even with all this, the Web (HTTP) is not a good way to access the data on the server, because the client usually loads all the code it runs from the server, and thus has to trust the web server not to serve malicious code. Otherwise the server can later do a http://en.wikipedia.org/wiki/Man-in-the-middle_attack such as a http://en.wikipedia.org/wiki/Replay_attack, to get the same data. And when I say the server, I mean the server compromised by some hackers who got root access credentials. And so forth.

In short, you will never have perfect security, just approximations. (Unless possibly if you make use of http://en.wikipedia.org/wiki/Quantum_cryptography)

Re: Ask HN: Securely store sensitive data in the DB?

#35

Post by buro9 »

patio11 got this right, if your application is able to decrypt it, then nothing you can will secure this data. Encryption is not the tool that you are looking for.

You can persist with encryption, but only if the user holds the key, ideally via 2-factor auth.

Instead of this, I'd go for whitelist of access, audit logs, monitors, rate limiting and alerts.

If you hold all the encrypted data and the keys, you only need your application server to fail. My personal view is that worse than thinking you have security is not responding (or even noticing) when the inevitable happens.

Configure your systems to be as secure as possible without going down the obscurity path, and then tripwire everything and know what unusual patterns of activity look like and who did what.

Re: Ask HN: Securely store sensitive data in the DB?

#36

Post by lifeisstillgood »

liquidcool wrote: post #31
orofino wrote: post #24

Earlier quoted context omitted.

To expand on this a bit, absolute security for encryption just doesn't exist. If you wanted your data 100% secure, put it in a database, disconnect the DB from your network, put it in a locked room, guarded by biometric locks and security guards. Even in that scenario, the data is vulnerable, but why even bother discussing that point, as the data is worthless if you can't access it. With that reality in mind, I was r…

I'm in ecommerce as well and I've seen PCI/DSS auditors require vendors/hosts to rearchitect using an encryption/key management appliance. You wrote you built your own solution - are there no known, trusted open source alternatives? As you mention, the appliances are almost astronomically priced, so it seems like an area OSS (or a disruptive startup) would help.

Love to follow up on that too

Re: Ask HN: Securely store sensitive data in the DB?

#37

Post by adg001 »

If statistics are considered sensitive, you can use cryptographic counters in lieu of their plaintext counterparts.

A cryptographic counter is a public string representing an encryption of a quantity, satisfying the following properties:

1. Subjects with access to the public-key can update the encrypted counter by an arbitrary amount, by means of increment or decrement operations and without first decrypting the value (i.e., the operation is performed over encrypted data);

2. The plaintext value is hidden from all participants except the entity holding some secret key;

3. The adversary can only learn if the cryptographic counter was updated (i.e., information about whether the counter was incremented or decremented is kept hidden to all participants except the secret-key holder and the updating entity -- honest-but-curious threat model).

An implementation is available at https://github.com/secYOUre/Encounter .

Re: Ask HN: Securely store sensitive data in the DB?

#38

Post by bradleybuda »

As many commenters have pointed out, there are theoretical problems with what you're asking for (if you can decrypt the data, then your attacker can too). But, there are some practical things you can do to make the attacker's life harder:

- Don't write your own cryptographic code or design your own crypto systems; use existing libraries as much as possible.

- Separate your reads from your writes. Using a public/private key pair, you can give one set of systems the ability to write encrypted data but not read it, and a different set of systems the ability to read the data. The systems that can decrypt / read data should be isolated as much as possible - don't expose them to public networks, limit which operators have access to them, etc. The separation also forces you to encapsulate your secure data and define an API over it; rather than arbitrary reads, hosts that don't have the decryption keys will have to ask the hosts that do to perform specific operations. If you're writing a Rails app, the Strongbox gem [1] enforces this pattern for you.

- Rotate your encryption keys.

- Don't store keys in code. Follow the Heroku pattern [2] of storing any sensitive data (i.e. private keys) in the environment, where it is bound at runtime to your code and encrypted data.

- Store as little sensitive data as possible. Make sure data you don't need any more is periodically purged.

- Human processes are just as important as code; keep track of who has access to sensitive data, make that access opt-in, and remove it when those people change jobs or are terminated. Do everything in your power to keep those operators from being phished (user education, two-factor auth, etc).

- Don't store credit cards if at all possible. Find a payment processor [3] to do it for you. It's not worth the headache, it makes you a more attractive target, and it may come with additional legal overhead (depending on your jurisdiction).

[1] https://github.com/spikex/strongbox

[2] http://12factor.net/config

[3] https://stripe.com/

Re: Ask HN: Securely store sensitive data in the DB?

#40

Post by bobsoap »

patio11 wrote: post #8
Eduard wrote: post #6

What is "CC data"?

Credit card data (numbers and the like, though probably not including CVVs -- the security codes -- because one should not be storing that in any form anywhere).

How are sites that store your CC data for later purchases able to charge your card without storing the CVV? Amazon, for example, and pretty much every subscription/SaaS product.
Post reply on HN