Keeping Private Customer Data...Private?

Suffering Sekret Keys asks: "When I first started working for the company I'm with now, back in 1996, I was charged with finding a way to keep our customer credit card info secure in our database. Now that I'm smart enough to realize the flaws in this system, I am wondering how you avoid the catch-22 of needing to be able to encrypt/decrypt the data on the same machine that houses it, without exposing a secret key that could make that data more vulnerable in the event of an intrusion?" This question has been submitted a few times, recently, but this was the best one out of the lot. It seems many of you are wisely concerned about private data stored on your company's net, and the risks involved if it gets stolen. Well, now is your chance to discuss various solutions. How would you securely store your customer's private information, especially when it comes to critical pieces like credit card numbers?

"I chose 1024-bit PGP encryption with a long passphrase. I use the Cryptix java package to handle the encryption from a Perl script (the reasons for this are legacy related, but I'm in the position where I can start clean if need be -- a Perl-only solution would be great).

The thing that makes me nervous is the secret key being stored on the machine that houses the database. The reason for this is so that our billing staff can handle the recurring billing. (They have a web interface where they must enter the passphrase to gain access to the credit card information.)

I have realized for a long time now that if someone gained full access to this machine, they could fairly easily run a brute-force attack on the encrypted data, if they found our secret key on that machine. But when we recently worked on our privacy policy, this potential problem became more important.

What changes could we make to our setup so that we can encrypt/decrypt the credit card information on the same machine that houses the data, while making it as hard as possible to decrypt the credit card data assuming the entire machine was stolen (or cracked)?

We are a very small company. How do "the big boys" handle these things? What is the best book on this particular subject?"

While this setup may work well for credit card numbers, what about setups that will protect other personal information like a customer's address and phone number? Would such information be practical to obfuscate in such a manner?

Comments

key storage

[Anonymous Coward]

Ive ran across this problem myself several times.
According to VISA rules, the merchant is NOT allowed to store the cardnumber - its the property of VISA.

To get around this, I dont store the card. I store its SHA1 hash signature. This is great because you're guaranteed to get a match on the card's record - but you dont have to store the cardnumber itself. This also enables great negative database checking without liability to the merchant. You've got the sig - thats all you need.

The key storage you're referring to is an old problem. The key is never secure as long as it's in software (software can be cracked, reversed,
analyzed...I dont need to explain this). The only secure way is to store it in hardware somewhere.

Secure co-host.

[vkg]

You answered your own question: you don't put the decryption key on the same box.

You put it on another box, close all of the ports, and have a simple protocol running over something low-level which you trust like SCP or a PERL socket reader.

Your "co-host" stores the secret key, and does all decryption: the main host passes it a datum to decrypt, the co-host decrypts it, and passes back the cleartext.

The key never leaves the box, and the co-host should erase it's copy of the key and shutdown on any unexpected network activity (like an attempt to log-in). If you're really paranoid, have it also look for patterns in the access and die if anything unexpected show up - or return bogus, flagged test data (i.e. a list of bogus credit card numbers in stead of real ones).

Does that answer your question?

Re:Secure co-host.

[Oestergaard]

So let me get this straight: You set up an "oracle" (a machine which you can ask to decrypt data and which will do so when asked). Your "security" lies in your "low-level" protocol (for which you obviously have communications code on the front-end machine).

Where's the security in that ?

Let's say I r00ted your front-end machine. Why don't I just look at your script or your binary and see that it sends the request over SCP. Or over a PERL socket reader.

You have added a very tiny amount of obscurity, but nothing that resembles security. Your "oracle" has no way of knowing who's asking, if you built the assumption into the system that "anyone who can ask must be in their good right to know".

Even if it's on a private network on another NIC, this doesn't help one bit. I r00ted your front end machine, remember - if the front end machine can talk to the oracle, so can I, when I'm root on the front end.

You may be able to add a little security resemblence with your "anomaly detection". However, it is quite likely that I am smart enough to just see how valid requests are built, before I try my own requests at the oracle.

Re:Why store cc# at all?

[Anonymous Coward]

And even more importantly - if you must store them, shuffle them off to a machine that is not on the Internet.

At my old company, there was a system which handled new CC number entries. As part of a nightly process, they were moved into a database on a separate machine which was only connected for that window of time. All of this was on top of standard security measures. So the biggest risk was having the "temporary" entries compromised.

What the Big Boys do...

[Frobnicator]

Many big groups don't emply the level of security you already have. Most bank 'security' is password protection and physical access protection. When break-ins happen they are not published; banks and credit unions are broken into quite often, and they pay to keep it out of the news. The unfortunate truth is that for big companies, it is cheaper to pay for damage from break-ins than it is to get good security to begin with. With the level of security you already have, look into business insurance. Tell them the precautions you have already taken and ask what would get you a better rate. (You would probably be a good risk for Insurance.) Implement those things, and have the insurer audit you in advance to make sure everything is up to snuff.

Re:What the Big Boys do...

[swb]

The unfortunate truth is that for big companies, it is cheaper to pay for damage from break-ins than it is to get good security to begin with.

This is the lesson lost on the Slashdot crowd.

Perfect security is impossible, good enough security is possible. Aim for good enough -- if you aim for perfect you will never achieve it and waste a lot of money trying.

Re:The Best Policy

[Vecna!]

If you bill a customer's credit card, you are required to keep that credit card information on file so that you can reverse the charges and/or provide information on charge traces that may be requested by the customer.

There's an implict social contract between the parties when a credit card is used - the contract is that in exchange for providing a good or service to you with nothing in the way of security other than reliance on a banking infrastructure, I will be allowed/required to keep certain private information about you so that I can validate my accounting records of our transaction on demand.

Keeping this kind of info is not being "up to No Good", it's fulfiling my obligations under the social contract.