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

dont connect it to the net

[Anonymous Coward]

Just don't. Credit card databases are too tempting a target for crackers. I've seen an ISPs card database hacked when they thought it was safe. It was a Netware server connected to the network, but with no direct internet connectivity. The cracker rooted the linux servers, then built the loadable IPX and netware kernel modules, mounted the netware server from the linux box (which the ISP people didnt realise was possible), and got full details of over 7000 user accounts. btw, in my experience ISPs *never* reveal stuff like this to their customers.

If you want it to be safe, use something simple and one way, like sending the details over a serial line with the rx wire cut. Cut off the database from the Internet as much as possible. Also try and restrict access within the organisation. The last thing you want is customers to find out their data has been stolen, if it happens remember you have no legal obligation to tell anyone. Keep quiet and maybe your company will still be around in 6 months time.

Re:Hashing - Seperate Retrieval Agent

[TheConfusedOne]

The ol' Public Key Private Key encryption is the answer.

Generate a Public/Private Key Pair on an isolated high-security box. Copy the Public Key to the Web Server where all the data is being received from. Use that key to encrypt the data and store it in a DB (preferrably on a box seperate from the Web Server.)

Once a month, the high security box will connect to the DB and use the Private Key to decrypt the information and transfer it to the pay agent. Configure this box very carefully and only allow it to talk to the DB box and the Pay Agent's server. Also, if you want to be extra careful keep the private key in a smart card and lock that up in a safe during the rest of the month.

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.

Careful-- your plan might be illegal

[ghostlibrary]

Be careful. I read the surepay site and couldn't find the specific terms of service (TOS), but based on experience with other sites (paypal, propay, instabill, etc), your plan may be illegal.

If they are going the cheap way (visit their site, buy via link to surepay, return to their site), then the TOS likely says "customers must enter information themselves" (merchants cannot just fill out the 'credit slip' for them).

This comes up even with some online merchant accounts-- that the _customer_ must fill out each charge slip that gets processed, and the merchant can't just fill it out for them.

It's a crucial difference that means implementing your own 'fake the customer re-submitting the info to mimic recurrent billing' could violate the TOS and, in turn, Surepay's own arrangements for their bank.

Of course, if they're using Surepay's premium, it might be do-able-- but that that point, between paying Surepay premium plus hiring you for coding, they're best off just getting their own merchant account and having you code locally-- and securely-- to do what they wanted in the first place.

Merchant banking is not a place for hacks.

Another idea...

[Primer]

1) Keep the data encrypted in the db

2) Keep the db on an internal 10.1.1.X network and only allow the db port to be accessed from the web server. Only allow ssh access from the dba's workstation. All this via firewalling, of course.

3) Use binaries for your web server programs, so that the encryption method can't be easily discovered if somehow your db server is compromised. Then, only allow the "update" priviledge to the db user that the web programs use, and...

4) Do the monthly billing directly from the database server via cron. The db server can be a 10.1.1.X machine and still have interet access via NAT.

5) Monitor your logs daily so that, in the event your web server IS compromised, you can stop them before any damage is incurred.

This crap about loading media and unloading it is not practical, since billing is going to be a daily occurence for most companies. The CC data will always need to be accesible. At least that's how things are where I work.

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

Wash your hands, Cover your Ass.

[BlueFrog]

If you're here asking us how to do this, you might not be qualified to handle this sort of security issue.

You have basically two options:

1. Hire a security consultant
2. Let your client know that they need to hire a security consultant.

Either way, you need to let your client know about this issue, and ensure that you're not going to be held responsible in the event of data loss/theft. Try to tackle this one yourself, without enough experience, and you're setting yourself up for a heap of trouble. Be a professional. Know your limitations.

Secure it

[Spazmania]

Here's how:

Overview:

1) Put the critical private information on an isolated machine.
2) Permit authorized processes to connect to the isolated machine in WRITE ONLY mode.
3) Permit authorized processes to connect from the isolated machine to the surepay server.
4) Permit no other connections.

The details:

Set up some database server software on your isolated linux box.

Write a custom interface from the main system to the linux box which accepts the data into a chrooted environment while running as a normal user (not root).
Write software which retrieves the data from the chrooted environment (still not root) and stores it in the database.

Write software which connects from the isolated machine out to the surepay server as necessary.

Set up firewall rules (a la ipchains) such that the only connections permitted are from the general-purpose server that the user interfaces with, and to (but not from) the surepay servers.

Problems with this approach:

1) Can't verify billing status e.g. credit cards in real time.

2) Credit card data remains vulnerable during the path between when its entered at the web server and when the web server stores it to the isolated server and discards it.

Possible Solution

[jrinderle]

Here is a solution using PGP:

1.) Generate a new public/private key pair of significant length using PGP / OpenPGP on a detached (off the network) workstation.

2.) Store the public key on read-only media. Create two copies. One copy should be kept in a fireproof safe. The other will become a mounted filesystem on the web server.

3.) Repeat step 2 for the private key. Except, both copies of the key should be kept in a physically secure (restricted access) location.

4.) Delete the keys from the offline workstation. Delete the swap file. Wipe the free space on the workstation's hard disk. Power off the machine to clear its RAM.

4.) Mount the public key as a read-only filsystem on the webserver. Read-only media maintains integrity. I recommend it for everything critical that doesn't require writes (kernel, system binaries, HTML files). Once there are cached in memory there is no performance hit.

5. Modify your web application. Encrypt client credit card numbers using PGP and your public key.

6. When credit card processing time comes around (every night, once a week), copy the encypted credit card numbers to removable media. Retrieve the CD with your private key. Batch process the credit card numbers from an offline workstation, decrypting the numbers with the pricate key on the CD-ROM. All of this can easily be automated with shell / Perl / Python scripts.

Again, it is critical that you A) have a backup of your key pair, B) maintain the integrity of the keys with read-only media, C) physically restrict access to your keys (most importantly the private key, but it never hurts to be paranoid). Also, your private key should never come near the web server.

Remember, document the process. Define policy to administer the process. Develop contingency scenarios (what is the private key is lost, compromised, the hard disk in the web server fails, etc.). Define how you will recover from breeches in policy. Train your employees to act responsbily.

There is a solution...

[nologin]

Use something else than Surepay. If it can't do what you need it to do, don't think you can easily throw a band-aid on to fix the whole thing.

While I can't be specific, I have had the fortune (or misfortune) of working with an e-commerce company. We had a golden rule w/ respect to storing credit card numbers. If you have a system to store credit card numbers in order to be able to reproduce them at a later date which uses a public info system (such as a website, etc.) the credit card numbers are vulnerable to someone stealing them.

Trust me. You'll never find a sure way of keeping that credit card number secure. You can say "I'll use encryption, store them (credit card numbers) on a secure server, blah blah blah". They won't be.

And I probably would trust a full end to end solution either. I just wish I can see the look on the face of a salesman who tries pitching his secure product when it's credit card numbers end up showing up in a Google search results page...

convenience vs. risk

[npkatz]

Buy.com, Ebay and (I think) Amazon let you recall card numbers you used before and use them on new orders. So they keep your old card around. I suggest heavy 2-way encryption with the key very well protected. The question is whether the card numbers are exposed, that is, if one of their employees or business partners can get to the data, is it readable or easily decryptable. If not, I say, you've done your job. I used to like knowing that companies that collect my credit card for payment don't keep it around. So the inconvenience of having to enter it again was OK given the security of their back end. However, having designed e-commerce systems myself, I realized that the lack of the recall feature has absolutely no bearing on the security of my credit card info. So I decided, screw it. Once you've used your card on a site to pay for something, you're vulnerable, at least to the dishonest employees of the vendor or his ISP. Now that I've settled, I really enjoy the convenience of being able to recall my card without having to type it in again. I would design every e-commerce system to have this feature if my clients decided it was right for their business. Norm