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

encryption

[paranoic]

Strong encryption and only connect the machine to any network (internal and external) when the bills have to go out. Filter all replies that don't come from the credit card responder.

Re:encryption

[Xzzy]

> and only connect the machine to any network
> (internal and external)

If you're unable to do this (due to staggered billing or something) the "next best" option is a heavily restricted network.

Give your machine with the personal information precisely one network connection and plug it into precisely one machine that can talk to the secured machine on precisely one port. Have your border firewall or equivalent drop any outgoing packets from either of these machines. Only let people do work on this machine from the console. Also use a straight cable between the machines.. ethernet port to ethernet port, crossover cable.

Then you have your webserver talk to the intermediate machine to handle transactions. Process submits authorization or billing request to intermediary, intermediary talks with the database, and issues a "yes" or "no" to the querying program. At some point you'll probably have to actually transmit user data to actually do the billing, so obviously everything in this chain will be encrypted.

Then install the best intrusion detection tools you can find/afford on all these machines and hire alert people to monitor logs. Treat any unexpected traffic as an attack and have someone walk over to your machines and physically unplug the machine from the intermediary until the situation can be identified/resolved.

This obviously assumes one believes that physical separation is important and effective, which I happen to do. ;) This also kinda relies on a security through obscurity standpoint, which contrary to popular belief can actually be useful as long as you don't let it lull you into complacency.

If server theft is a concern you'll also want to yank out floppy drives, physically secure the server somehow, look the bios, and if you absolutely require being able to copy data to this machine give it a read-only cdrom drive.

IMO, I wouldn't back up the server except for a hard drive image you can use to reinstall everything to a known state. Were I joe online shopper, I'd much rather re-enter cc info than worry that tapes were floating around the country with my data on it.

If you did even half of this, you'd have several times the level of safety than I've personally seen on some other online merchants, and I've been through a good number of data centers.

Amazon.com

[Anonymous Coward]

I remember hearing that Amazon.com originally used a Slackware box with extremely limited connectivity as a 'store' for the credit card info. Set it up with extremely limited connectivity, i.e. on a subnet unreachable by the world. Put only extremely limited services on it, i.e. set it up so there's a pipe for credit card info to get onto the box but nothing on the box is shared out and there's just one data path out from the box that sends an 'okay' signal that info verifies correctly. The machine should be set up so a zip drive is the only way to get info off of it, and you have to sit at the keyboard to do so.

Using GPG always appealed to me

[Anonymous Coward]

I always thought that this article described a way thats pretty simple, and easy to use / develop.
Cheers.

But it's still on the server

[A nonymous Coward]

If someone cracks the web server, then they also have access to the web server code which decrypts the database info.

If it's readable by the web server, then it's also readable by a cracked web server.

You really need the secret info on a separate machine, with the CC machine never regurgitating anything except a simple answer (valid / invalid) in response to the full set of info (CC#, expiration, name, address). The only info a cracked web server can get is answers to random info, and it would take too long for the cracked web server to try random possibilities.

Re:Hashing

[pitcrew]

First of all the biggest risk is from internal theft. This can be handled by keeping the box secure both physically and from the internal/external network. Secondly the processor must get the data in a usable form thus it must be transmitted over the Internet as open text unless the processor has an encryption they want you to use. I solve this problem by sending the information to my card processor over dial-up lines. Yes it is slow, (1200 baud) but I can process 800 credit cards in about 45 minutes. The problem that I see for you is not the storage of the card info but the transmission over the Internet. You mignt want to look at ICVerify. This is piece of software that has been around for a long time and works fairly well. You can also process in real-time if you need to for sign-ups.

Re:Cart before the horse

[sharkey]

You may want to reconsider CCBill. Apparently, in March 2001, they were notified of an insecure CGI that exposed their merchants login information. They removed the CGI, but didn't tell their merchants, apparently hoping to sweep it under the rug.

SurePay is being discontinued

[Animats]

SurePay is on the way out. They've made a deal with Verisign to migrate users to the Verisign Managed Payment Gateway. The SurePay gateway is only being maintained for existing customers. It should not be used for new development.

Not a simple problem

[geraldthewes]

I've build similar systems in the past. It's not a simple problem. In addition to a very robust and well thought network architecture and a very robust encryption architecture for the Credit Cards as mentionned in the previous posts you have to deal with:

Credit Card reconciliation - when you bill on a monthly basis, a lot of cards expire, are cancelled, this needs to be detected, the user informed the next time he tries to use the service, etc... There needs to be good adminstrative/financial metrics to track these.

You need very good operational interfaces and a strong underlying architecture so that people get billed when they should, and not when they should not. It's easy in cruise mode, but harder to keep track as financial processors or external connectivity is down, or after an upgrade, or system crash or other usual operational down-time.

Things get also quite complicated quickly if you offer multiple subscription services (monthly, yearly, first month free, etc...)

This stuff is hard to get 100% right (and it needs to be 100% right). I agree with the other post that recommend either a provider that already does that, or buying software that already does this.