A Proposal for Secure Storage of Credit Card Data

A customer asked for advice on how to secure their storage of customer credit card data, which to date has been done essentially in cleartext with no real protections. I was really surprised to find that there just isn't much big-picture advice, just "encrypt the database".

I'm not any kind of crypto expert, and it was frankly a little scary to go down this road even if using known-good algorithms (such as RSA), because it's really easy to do it badly. But, never one to be daunted by my own ignorance, forged ahead.

The result of this adventure is this Tech Tip, which raises issues that the others and I were able to think about. This is more about how to think of the problem in the big picture than it is about a recipe for a solution in a particular case. Indeed: I didn't touch on specific of my customer's environment.

This has circulated privately for some time now, and so far nobody has pointed out any bonehead issues, though many have made suggestions that were good but were not applicable to our environment.

With all the headlines about 50,000 or 500,000 identities being stolen due to poor information security, there ought to be a lot of enterprises thinking about this road: I hope that this paper serves as a useful starting point for them.

Feedback (including "that's a bonehead mistake") welcome.

Unixwiz.net Tech Tip: A Proposal for Secure Storage of Credit Card Data

Comments

[i386]

I have been thinking about a good way to do this... I may just come up with the way one day and write it in C, and release it all over the Internet.

Using a computer that only a network system (10.0.0.* / 192.168.0.* / 192.168.1.*, etc.) can access, and not an outside computer (69.*, and the millions of other non-IANA-reserved netblocks), that would be pretty secure. There'd be a server and a client.

The client would have a text file, '.request', which would have data to request in it. Then you'd immediately SIGUSR1 the process (killall -SIGUSR1 cc). It would get your data and add it to the '.response' file, where you could then get your data from a PHP script or whatever.

If you try to kill the client/server processes, it'll just start up again, as the server accepts 1 concurrent connection. More than that would get it to not accept() the connection. That protects from the following situation:

1. Some hacker roots the Web server
2. The hacker decides to get some CCs. So he tries to use our network IP (10.0.0.1, port 2353) to connect to it. The server doesn't accept() the connection.
3. So he decides to kill the client to try again.
4. The client starts up again, so it isn't possible for him to do that.

And the client would start up again on ANY signal, except SIGUSR1 (which won't even try to close it).

seems like it might be a great system. I will write it and try it.

-i386 (i386 on DSLReports / BroadbandReports)