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

big companies

[Anonymous Coward]

If work for a big bank in Canada (about 3 million clients), and you would be surprised to know that out databases are NOT encrypted in any way...

In fact the sole security rests on the passwords and the physical access to the machine.

But our servers are in a secured building, administered by IBM (you should see what it takes just to be able to enter the computer room, let alone trying to stay 1 minute in front of a console without someone asking you what you are doing there...)

Re:Why store cc# at all?

[realdpk]

It's not unusual for a merchant to ask for your credit card to process the refund. So, they ask for that again, and it's compared against a hash generated from the original order. Tada, easy as pie.

Security needs to be in place in all levels

[puppetman]

Our credit card info is stored encrypted in our Oracle database.

No one accesses the credit card info directly - we generate reports for billing staff. When credit card info is sent across the net (to process charges), we use secure sockets (as does everyone I'm sure).

The only machine that knows how to decrypt is a weblogic app server with the key, running on Solaris.

The database is on one virtual LAN, the webservers on another, and the app servers on a third.

We have PIX firewalls to keep out intruders, and our boxes are physically locked down in a cage.

In addition, our hardware topology is based on Windows 2000, Linux and Solaris. You would need to take advantage of security flaws in all three OSs in order to be able to traverse our site.

We make sure the passwords are not words or phrases. Numbers, funny characters, and letters.

The holes in our system are:

1) On weblogic, the connection info to the database is out in the open in the connection pools.

2) Billing staff need to be careful with how they handle paper reports. Perhaps we should only show the last 4 digits of the CC number when generating.

3) We refresh our QA environment once in a while. I have to be sure that I wipe credit card info, passwords, and email addresses from the QA database. While it's fairly secure as well, no point in leaving it around.

No system is perfect. So long as they are encrypted, on a machine that has the latest security patches, the machine is in a secure environment, and the passwords are "strong", you can sleep at night. Most of the large credit card thefts have been against systems that violated one or more of those rules.