Responsible Handling of Billing Information?

moving on asks: "I've been asked by a client to build a fee based subscription service using surepay as the vendor for processing credit card transactions. Subscribers to the service will be billed X amount per month and that is the rub. Surepay does not offer recurring billing so I will need to store credit card numbers and related info. The question is then, how does one best do this in the most responsible manner?" The trick here is giving consumers the service they have come to expect from most websites, without exposing their personal information to would-be thieves. Do you think such a system is possible?

Comments

Good practices

[Pinball Wizard]

Here, in a nutshell, is how I do it.

1 - I use OpenBSD for firewalling. You limit connections to your machines by only allowing specific ports to connect to that machine. You can also control which way connections are allowed to connect. For instance you might wish to limit connections to your web server to port 80. For the database server that will hold the credit card data, a good way to do it would be to allow port 22 into the server, and no traffic whatsoever to leave the server.

2 - Use private key encryption. There is no need for anyone but you to have the key so use a good private-key encryption on your data server. Triple-DES is a good choice. It comes free with OpenBSD

So, basically, what you need are two OpenBSD boxen, and the expertise to set up two firewalls, SSH, and Triple-DES. Then, to get your data, a cracker has to 1)Crack two OpenBSD boxes 2) Exploit a hole in OpenSSH 3) brute-force Triple-DES.

In other words, they will be having snowball fights in the ninth layer of hell before someone gets to your data.

My solution

[Amorphous]

Howdy,

here's what I did when I implemented the same kind of service:

first, I choose PGP (GPG) to encrypt the user's CC information in a database on a safe Linux system (firewalled and using an IDS).

here's my logic: information can be encrypted anytime using the public key, but the private key must be used for decryption. The public key is then stored on the server, but not the private one.

In case of stealing, you're safe so far.

Only one program access the CC information and need the private key. On startup, it asks for two information: the "real" private key and a "passphrase" of a minimum length. the key is then XORED with the passphrase and the result is hidden in memory. The passphrase is then given to the employees and changed daily (or anytime you wish).

So the CC info can be read if:
1- the server process was started by a thrusted admin knowing the private key, and
2- the person accessing the data know the day's passphrase.

if the passphrase is protected while being sent to the server and the employees are either "thrusted" or "unable to hack a secured unix system and debug the memory to restore an xored key", the system should be safe enough

backups can be made (the key's nowhere nead the hard disks) and the information given to the employees, the passphrase, can't be reused after the end of the day.

and if it's not secure enough for our most paranoid contenders, it's fun to realise anyway :)