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

Comment removed

[account_deleted]

Comment removed based on user account deletion

The above is the best solution

[jabbo]

and I've implemented reasonably correct versions of almost all the others, so I am not just 'guessing' but offering observations from someone who's built several systems like yours.

You want accounts and you want them managed separately from billing. Physical security is what should realistically protect the private payment and identification information that relates to those accounts (eg. the substance to their metadata) so that day-to-day manipulations of orders are separate from month-to-month billing updates.

You simply must keep private info private and enforce it via legal and policy measures. No amount of technology will easily prevent misuse of your data. You could, however, experiment with CryptFS or StegFS to make it much more difficult for a physical security breach (eg. stealing the machine) to result in information leakage.

When I went back and reviewed the submitter's question I decided that I had focused on the wrong aspect of his question. One-way encryption (outside-to-inside) is important, and it can be keyed to the same database as customer account identifiers, without divulging useful information on a public interface. However, the primary measures for his company to take are still going to be policy (dissociating private customer data from public/unimportant customer identification data) and legal (physical security, pressing charges when anyone tries to circumvent).

Again, every measure I'm discussing above is something I've had to deal with in my job, and I am merely offering opinions as to what has worked best for us. I design my systems (at least at this point in my career) so that, for the most part, someone could steal them outright without greatly affecting our day-to-day operations.

Re:The Best Policy

[hexx]

The Only Best Policy is: Don't store private information, ever.

It's easy, meaningless, hackneyed non-answers like this that are eroding slashdot.

I ask "What the best way to do X", and the highest modded answer is "You silly boy, don't do X". Well, if "not doing X" were an option, the question would not have been asked.

People need to understand that virtually any question can be inappropriately (and quickly) answered with "do something else", but then that's not a real answer. It's an excuse to vent an opinion (just like this rant).

And really, it's the moderators who are to blame.

The parent (and this post) should be modded as -1 offtopic.

NEITHER ONE ANSWERS THE QUESTION OR OFFERS A REASONABLE ALTERNATIVE. They both preach. Blah.

I've had enough.