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.

Re:encryption

[merlin_jim]

What about the storing of the credit information? That will most likely be coming in at arbitrary times, and thus the credit storage machine will need to be connected continuously.

Look at the guidelines in the Visa CISP. They have good information about this... the bottom line is: use asynchronous encryption (store your private key elsewhere and use it once-monthly to decrypt the data as you send it), use a firewall, and patch your OS often.

Cart before the horse

[rhizome]

Why not use a billing service that supports the subscription model you want, rather than trying to find some minefield-laden path toward storing credit card info?

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.

Re:Cart before the horse

[crucini]

Because if you are working on a project of any serious size, the selection of merchant bank will be made by finance folks on its own merits. They are not going to accept a clearing provider with a slightly higher rate just because some programmer prefers their API.

Your advice is applicable to very small net businesses. It is unsuitable to serious e-commerce sites because, among other things, it leaves you completely at the mercy of the clearing provider. Imagine sending an email to all your subscribers saying "Dear valued customer, due to a dispute with our former clearing provider we have lost your card number. Could you please take a moment to go to https://...." You would lose a substantial portion of your hard-won userbase that way.

duh...PASSPORT :P

[BlaKnail]

Just fork over money to Microsoft, and they will provide you will access to an ultra-secure passport server, so your clients will have nothing to fear.

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.

How does Surepay store it?

[mESSDan]

If the question is how to store data in a responsible way, why not ask Surepay, who you are sharing the sensitive data with? Surely they will have some insight into this, and because you are a client, may be more apt to share it.

Maybe your question could be asked how to safely transfer it?

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.

Make sure you use encryption

[f00zbll]

Reguardless of what ever language, platform or server you pick, use encryption for sensitive information like credit card number, expiration date, and name for the credit card (in case it's different). Typically in an enterprise environment you want to use one way Hash for the password and dis-allow retrieval of the password. If the user forgets their password, they get a new password and are forced to change it when they login the first time. Yeah, it's more of a pain for the user, but it's the responsible thing to do.

Use DESEDE or something equal. The main goal is to make it so if someone break into your database, they can't get clear text passwords, credit card numbers or expiration date. If you want to be really hardcore, you can have a different secret key for each user, which is decrypted at runtime to generate the appropriate key used to decrypt the credit card information. Make so that once the system is up, no one can get credit card information without asking the customer. This way the information is only in plain text when the charges are made to the card.

storing info in a "secure" location.

[spotter]

I've thought about this problem a bit, but never really had to implement anything, so anything I am about to say, should perhaps be taken with a grain of salt.

One assumes that the web server is insecure, and therefore is going to store the data on another "secure" machine.

One needs to make a very specific interface that one can use for the "insecure" machine to talk to the "secure" storage machine (this is the machine that is going to do the cc verification also)

Presumably, the "secure" machine is not going to be running any services that are accesible to remote users besides whats needed for the the web server to talk to it. One can do something like only allow the machine to talk to the "insecure" webserver, but this doesn't buy you much more security, as all someone has to do is crack the "insecure" web server and you are at the same place you were before.

Getting back to the interface these programs speak. One basically needs an "input" func, and a "status" func.

Basically when one register with the site, the werb server doesn't store any information about the credit card on itself, as it immeadily connects to the "secure" machine and uses the input function to inform it about the new account.
It can then use the status function to determine that status of that account

status can be OK, or NOT_CHECKED_YET, or NOT ACCEPTED or the like. but basically something that is read only by the server.

Both of these services should be easy for the "secure" machine to check that its getting properly formed requests (i.e. is someone is trying to attack it). One can also make a script that then verifies each account each month, and since one can do this over a phoneline, you don't even need to allow any other outbound connection from this machine.

yes, a little bit more thought probably has to go into this, but this is what I came up with a while ago. feel free to criticize away.

Lockbox, & let the customer decide...

[bourne]

Though there is no really good way to do it, the safest way to do it is to isolate credit card info onto a seperate box, limit the access to that box to the absolute minimum required to request a charge, and have that box then directly contact the credit card clearinghouse rather than return a CC# for use by the other half of your application.

Encryption (SSL minimum, preferably also encrypted in store with keys being supplied by the other half of the application) is necessary, the lockbox code needs to be as limited in capability as can be, and what remains must be thoroughly audited to limit the likelihood of breach. No other services should run on that box, and physical access must be tight. A shared cage at Exodus doesn't do it.

Whatever you do technically, I think the most important thing is... don't forget to let the customer decide. Any app that stores CC info should allow the customer to decide NOT to have their info stored. I rarely see sites that allow me to "opt out" of having them store my credit card info, and I'd rather retype it than trust them.

Re:Lockbox, & let the customer decide...

[jayfoo2]

Actually.....

Even if they are not storing your credit card info for you to use again (i.e. a profile) they are almost definately storing the info for their own reasons.

The rationale behind this is that when there is a chargeback (when a customer tells their issuing bank a transaction is fraudulent or otherwise bad) the merchant is responsible for convincing the credit card company that it was a good transaction.

The problem is that when Visa and MC tell you that you have a chargeback all they give you is the Credit Card number, date, and amount. You need to have stored in your system the details of the transaction linked to that credit card number. Otherwise you can never fight chargebacks and you'll get screwed (for aboveboard merchants ~.4% of transactions result in chargebacks).

So it's unlikely that anyone who knows what they are doing would build a system that doesn't store your credit card data. Hopefully they are securing it well.....

Internal Controls

[jayfoo2]

Absolutely key to securing financial data (or really any data) is the use of good internal controls.

Most technologists spend a lot of time securing their data from external attack (i.e. a cracker). This is important but it is not the most likely threat.

Well over half of all thefts of financial data are committed by employees/trusted users of the company. Sometimes by the people who maintain the system and sometimes by others.

You combat this two ways. First with technology, the system (in this case probably a database) that contains the data should be access controled. It is also a good idea (and required by visa/MC) to encrypt the data. Another thing to watch out for is that you are not putting the credit card data into any other places, i.e. log files. you need to physically control access to the hardware running the system. Finally watch out for your backup tapes/media, especially if they are stored offsite.

On the soft side you want to have good audit controls on the data. Whatever method is used to access the data should leave a record of it doing so in a manner that is hard to compromise. People who don't need access to that data should not be allowed near it. Finally you need to be able to trust the people with access to the sensitive data, depending on the level of sensitivity this could involve cursory or invasive background checks. Banks background check their employees rather carefully, and for a reason.

"My Honda isn't a Ferrari..."

[somethingwicked]

I see this same mentality on some of the car related boards that I go to (luckily appears that this is not the programmer's requirement for Surepay)

Some things you can "sup-up", but certain features don't come on the Yugos of the world...Good luck on reprogramming the manager instead

Hire the right experts.

[bluGill]

Bruce S. (I'm not gonna try to spell is last name) of Applied Cryptology fame is where I would start. Read his books, do a formal design of the system, and then hire him/his company to aduit your design BEFORE you start coding.

Don't forget to have a range of secure systems to work with. Run the web server on openBSD, and have the dataBase on trusted solaris. And use a good database and firewall (none come to mind off hand. (Note I'm giving examples, you can mix and match to please, just so long as they have to break several systems to get the data, none of which trust the others)

Take the additude that your web server will be cracked. Do your best to detect that. your firewall should protect the database (unless it is hacked!), and the database doesn't trust the firewall. With good detection you should shut down the front line systems before the cracker gets to the back end.

Remember to have experts aduit your design. Have other experts audit your code. (the later is hard, but it helps a lot)

Information wants to be free

[Dionysus]

Why encrypt it? Kinda parasitic to keep information from people, isn't it? And they're not thiefs. They're information liberators.

Ditch Surepay...

[Brendan Byrd]

If they don't support recurring payments, maybe that's the initial problem. I guess your PHB doesn't like that idea, does he?

In terms of security/responsibility, it's impossible to create a 100% secure system, but as long as security is a focus in your software (and it isn't rushed), it's destined to be as secure as possible.

I guess I could list a few pointers to help you out, though (in random order):

• Don't trust HTML pages to give the correct limitations and forms. People can change local copies and send any data they want.
• Never use "secret" URLs, unless you use some sort of HTTP passwording system, or something else similar. (This has been the cause of many data-theft attacks.)
• Encourage customers to use secure passwords, such as 6+ characters, letter/number & upper/lower combos, no dictionary words, etc. (And for god's sake, let them use spaces, if they want.)
• Store billing information in a seperate system than the web server or any other system. Put the billing server behind the firewall on a private-class network. If one gets hacked, the billing data is safe.
• Make use of that 3-digit number on the back of CCs to verify that they aren't stealing numbers. (I really don't know if that's possible, but you should investigate it, as it would curb a lot of usage on stolen CC numbers, unless they have the physical card.)

NIH?

[hey!]

There's lots of issues with storing credit cards, not the least is showing that individuals working for you can't misuse the data and would have difficulty even colluding to misuse the data. I know, I was a IT director in the pre-dotcom days when people took these issues seriously.

Hopefully, there will be some insightful answers posted to /., but I think there are some other parties you may wish to ask. If you have a good CPA, they will know how this issue is handled in related businesses. Also, don't forget the credit card companies themselves, who should be willing to share their ideas for "best practices" when using their products. Remember, they have a vested interest in making their products convenient and safe for vendors to use.

Finally, this seems like a commodity sort of task that involves lots of headaches to get right (like payroll). Perhaps it would be better to buy the solution from a vendor/service beureau that can handle your requirements and so you can concentrate on the things which differentiate you. If,on the other hand, you are in the business of managing this kind of information you should have people on your team with considerable real world experience in this.

Good luck.

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.

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:Split up the CC#

[GigsVT]

That is the worst idea I have ever heard. Suppose you decide to store the latter half of the card number in a cookie, and some other site decides to store the beginning part in a cookie, using your method, bam plaintext credit card number on the user's computer, which is probably the least secure place for it to be stored in plaintext, since they probably have an open read-write SMB share hanging out from the latest MS worm.

This goes to show why it is very dangerous to "Ask Slashdot" about anything important or security related.

Re:Why don't you ask a porn provider

[GigsVT]

Yeah ask CCBILL, they are secure, so they say.

Too bad /. rejected the CCBILL story, it's probably the biggest breach of security in recent years.

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.

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.

Re:Paper

[Skirwan]

Yeah, and when you take a cold shower, you probably turn on the hot water for 20 minutes until it's cold.

Abusing unintended timeouts in your hot water supply to access cold water through hot-water channels may be a violation of the DMCA. Please be advised that hot-water channels are to be used solely for the transport of hot or lukewarm water, and that any other use is prohibited by your license agreement. Sharing information that may allow others to mis-use common hot-water channels in unintended and undesired fashions is irresponsible and may leave you liable for criminal damages.

--
Damn the Emperor!

Choose the payment software wisely

[phamlen]

1) As other people have mentioned, the biggest decision is which pay service to use in the first place. The wrong package will result in you:

implementing strong security on a system, which is difficult to do right

implementing a lot of customer service tools (to look up credit card numbers, issue refunds, track chargebacks, etc.)

generally spending more time than necessary in order to poorly implement something that another company has already done. Remember, the billing services are the ones who should be figuring out how to store credit cards, be secure, etc.

2) The place to look for payment systems is: here

3) Be sure to understand the Customer Service issue. It is quite reasonable to expect that Customer Service will ask to be able to "look at" Credit Card numbers, but consider carefully whether they need to see the Credit Card numbers or just search on the credit card numbers.

In my experience, you may end up spending more time writing the customer service interface than writing the customer interface - they may need to issue refunds to a card, they may need to investigate chargebacks (a BIG issue - especially with recurring charges.)

4) Avoid storing the credit cards if at all possible (but understand how you'll issue refunds and search for credit card numbers). As everyone states here, the security required in order to make this secure is easily weeks worth of effort. Again, picking the right payment service can eliminate this effort.

5) Remember, the client probably doesn't care about security enough to jeopardize payment - this is a clear case where the client probably wants his money more than he cares about preventing "potential attacks".

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

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.