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?
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.
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.
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.
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.
I always thought that this article described a way thats pretty simple, and easy to use / develop.
Cheers.
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.
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.
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.
No, Thursday's out. How about never - is never good for you?
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.
Infuriate left and right
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.
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 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.
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
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.