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

Re:your first problem

[baudbarf]

I suggest you change your solution to run on Win2k.

Ah, yes, if you want to increase your security, run a Microsoft OS. And if you want to increase your protection against STD's, use condoms manufactured by Firestone.

avoid the problem

[dan_bethe]

One way for small businesses to deal with the problem would be to avoid it by using Paypal. They're a reputable financial institution which can broker the exchange for you. You would never know the other party's confidential information. Some small businesses distribute their payroll to independant contractors that way.

On a related tangent, here's another question. Do you guys have any recommendations for a low end credit card purchase system requiring low or zero startup fee, but rather charging a per-transaction fee?

I have the answer!

[Ribo99]

How would you securely store your customer's private information, especially when it comes to critical pieces like credit card numbers?

On my Palm Pilot.

Learn from the past

[L. VeGas]

I would consider storing the numbers in Navajo. It worked in WWII.

Re:big companies

[Anonymous Coward]

> If work for a big bank in Canada (about 3 million clients), !
I don't think that the National Bank of Canada whom have 3 million client can be considered like a Big Bank !
Anyway who can trust a Bank who need IE to access it's "Secure" Internet banking

Re:Secure co-host.

[GigsVT]

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

Worker 1: Holy shit Bob, the web site is down again!

Worker 2: Yeah, every time someone enters a bad card number or tries to log into our security box, we lose thousands of dollars, but at least our customer's data is secure!

Microsoft is going to be pissed ...

[TheViffer]

you have reveiled thier new security strategy after the month long security audit they did.

Re:Securing the co-host.

[Ashurbanipal]

Make sure the co-host is not networked at all; have the connection be a pair of RS-232 serial lines instead. On the line that sends the data to be validated, clip the wire that would allow signal to be transmitted back - (break RD, leave TD intact) to create a one-way signalling method.

Go/no-go decisions are signalled on the other link, either with simple sense carrier signalling (wire CD to DTR or whatever) or a very restriced set of allowed responses.

Programming the system is a pain in the ass since you have to use the console, but once set up it should be so simple it'll need no other maintenance than backup tape loading.

Any cracker who can figure out how to break your system when you have no net link is so much smarter than you, you're probably doomed anyway!