Slashdot Mirror
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?
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?
When I was a kid, we only had one Darth.
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?
-- Dan
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.
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.
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.
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
---"What did I say that sounded like 'Tell me about your day?'"---
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.
I've had enough abrasive sigs. Kittens are cute and fuzzy.