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.
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.
Then how do you send the credit card info off to the billing service?
/etc/hosts.(allow|deny) ] from the web server and strictly firewalled from the rest of the net and segregated from the local network too.
They're gonna look at an MD5 hash and ask which part is the expiration date =)
The real key is limiting access to the machine housing the database, and strengthening the security/encryption used to move that data around.
The db server should only be accessible [
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)
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.....
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):
Zodiac Survey
Visa has some pretty clear rules about what online sites should, and shouldn't do, with credit card data.
Single sign-on, encryption, restricted access, with (potential) fines for vendors that cause excessive problems. With these, Visa claims a fraud rate of 1% was dropped to 0.06%. If it were me, I'd work with either the CC processor or Visa to work out recurring payments. Make sure you're not legally on the hook for any mistakes or breaches.
My wife uses throw-a-way numbers, I change them at the first hint of a fraud problem -- both are going to cause you headaches.
I hate vendors who back-end credit card information and work very hard to avoid them. You could do us a big favor and alude to the vendor (so we know who to avoid).
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.
/., 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.
Hopefully, there will be some insightful answers posted to
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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
Yeah ask CCBILL, they are secure, so they say.
/. rejected the CCBILL story, it's probably the biggest breach of security in recent years.
Too bad
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.
One would assume that you don't allow all sorts of evil things past your firewall. Lets expand on the intent of what you are trying to do and also assume that there needs to be internal access to the data as well--customer support, phone registration, etc. What would you do in that case?
Certainly you can wrap the calls (client or web) in something like SOAP/XMLRPC/RMI/Corba and then use an encryption package over it. I built something similar to talk to a credit card authorization system using XML over HTTPS with the Java JSSE library extensions. You could certainly do this internally and to the remote authentication system as well.
The problem most sites seem to have is where the data is located and how access is allowed. Provided you are not putting your client info DB out on the net and leave it inside and protected you shouldn't have much of a problem. Do customers need to change their credit card numbers? One assumes they do and will be prompted when the card expires. This means the web server needs to have access to that data. If not, lock it inside your network and only allow writes to the database and reads only to the monthly revalidation program. In an ideal world, the internal program would have a direct link to the payment system and not have to use the net at all. You should really try to build some data abstraction layers into the system so even if the web server is hacked it can't be used as a platform to run SQL statements directly against the customer data DB. Most of the posts here seem to be about encrytion and the like, but in reality if you allow access by the web server and it is hacked you are pretty much SOL if you have a visable API through a server-side scripted language. Just IMHO.
-J
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.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
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.
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
It's worse than that. The beginning part of the CCN is just a designation for your bank.
If you want to store the info on your own servers the best solution for you would probably be ModernBill. It offers an integrated signup process and user management. It can also automatically talk to payment gateways such as AuthorizeNet. Highly reccomended by many. Check out http://www.modernbill.com.
If you want to keep your customer info offsite you can check out Ubersmith, which is provided by voxel.net. This is also very good and I know many people who use it. The only problem here is price. It's rather expensive to go this way, but if you can afford it it's probably the best way to go.
Hope those all help. ;)
[Got Hosting?]
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".
If you have to ask this question on Slashdot, then you shouldn't be doing it. Read "Secrets and Lies," and then think about the question some more.
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.
I have used IBill for two years for recurrent monthly billing, and I am delighted with the service. They have great customer service. http://www.ibill.com
Here's what Visa recommends to merchants:
Internet [firewall] web server [firewall] app server [firewall] database server
...and the database must be encrypted.
Check out a company called Protegrity; they offer drop-in encryption for many vendor's databases.
It's supposed to be completely automatic, but actually you have to press this button.
Giving customer's the service they expect isn't the hard part. Any software engineer who knows Perl, Java, or C++ should be able to implement it without much difficulty. If you think that is the hard part please do not work in e-commerce.
The hard part, the meat of the problem, is securing the data. And it's a problem who's difficult is often underestimated.
I'm assuming that all data is submitted ONLY via 'POST' (i.e. not 'GET'), and via SSL. If this is not the case, see the above comment on working e-commerce.
I had to design a system like this for the e-commerce company I used to work for. Assuming we where hacked and how, the goal was to minimize the impact it would have. E.g. if the hacker got access to our entire source tree, our database, had a network sniffer, etc. how would we stand under various scenarios. Additionally, we made as few assumptions as possible (e.g. the hacker could have access to our source code, the public key, our db, network sniffing, but did not have access to private the key).
If you're past that, some advice:
1) Place all your secure data on a separate server. Minimize the data present on that machine. This will decrease the likelihood of someone needing or asking to get access to data that will additionally expose the secure data. Additionally the server should be as stripped down as possible, as any secure server should be.
2) Setup your network with an additional zone. The server mentioned above should go in this zone. The new zone will be strictly controlled and only used for holding the server upon which the secure data will reside. This zone should be strictly controlled with it's own router. Everything disallowed and only one or two things (ssh and https) should be opened. Ideally, if your main webserver (probably the most likely spot for a penetration) you'll want to know if this part of the network has been breached as well.
3) Do not write the secure data to disk (e.g. in log files or in debugging information dump files). Do not pass the data over the network in any insecure manner. This seems obvious, but a lot of people fail to understand the entire environment, and can inadvertently weak their system's security due to this. For example, many people using a servlet container like Resin configure the session data to replicate to another server. While this is a great thing, and reduces the problems of losing any single server, the secure data can be transmitted across the local network in clear text while being replicated. Not good.
4) The web servers will most likely need to make a secure connection to secure box. This sounds bad at first, but there isn't a better away around it. Ultimately the data has to get from point A to point B. Writing it to disk for batch accumulation is not good (as stated above). Building up a queue and batch submitting jobs to the server doesn't really offer anything over individual submissions. Additionally it increases the detriment of a server crashing before the batch job has been submitted. In some cases this might also be less ideal as the business needs may call for pre-auths to take place as soon as possible, or otherwise sending the order to a distribution center as quickly as possible.
5) It's obvious to state you should encrypt the data before writing to the database. The part most people miss is HOW to encrypt. Just using a public/private key isn?t enough. Even worse, most folks will miss judge the strength of their system by gauging how long it would take to crack the key being used. While cracking the key is most likely what you would want to do to read the secret message from Alice to Bob, it?s not what someone is going to do to get your credit card numbers.
If someone wants to get your list of credit cards, it's easier to brute force the number. The average non-amex card is 16 digits. Assume you've gotten the entire database; you'll have a few hundred thousand numbers easy. Assume you're not a greedy hacker and would be happy with say only a hundred thousand numbers. Then the first four digits really aren't random as they often represent the network and bank. (Ever notice that your buddy?s Visa card also begins with a 4? Or that everyone?s Discover card is 6011?) That reduces the complexity by four orders of magnitude. Often the last four digits are show plain text to the customer. That leaves only 10^8 combinations to try. Additionally a clever hacker would do a quick mod-10 check before a more expensive encrypt-and-check call, so that's really not that long.
So what to do?
Using a one-way method isn't an option. We need to be able to get the original credit card number back. Not just because of the case cited above, but that's just a real-world need. You cannot legally charge the customer until an item has shipped. If you can't ship right away (i.e. Backorders), you're going to have to hang on to that number and use it to charge the card latter. If you have to break the order into multiple shipments, same thing.
What we is an asymmetric encryption algorithm. One that will generate a different ciphertext each time the cleartext in encrypted. There are a lot of ways to do this, some encryption even provide for it. If not, simply append a delimiter and a random number to the cleartext and encrypt it. (E.g. instead of encrypting '4111-1111-1111-1111' encrypt '4111-1111-1111-1111*4873924839432432432'.) If you have the private key, it is easy to discard the random text. If you do not have the private key, this makes it difficult to brute force the number.
6) Backup should be done separately, to separate tapes, on a separate drive connected directly to the machine. The tapes should be treated as access to the machine would be.
7) Tripwire the private key. In case of a breach, you'll need to know if this file has been accessed.
8) Use stored procedures to restrict access to the secure data. I love m(y)?sql, but this where Oracle and SQL Server's stored procedures are really nice. Basically the account through which data is being accessed by the applications should not be able to select, update, delete, or insert. Instead offer a stored procedure API to do what is MINIMALLY needed. Generally it's best to offer a minimal, but complete API. That's not the case here. Offer only what's need (e.g. do not provide an interface for updating a card number if that?s not needed, etc.)
9) Chargebacks and coupon abuse are going to be a pain in the ass. The draw back of the above method is that you cannot easily find an account by credit card number. And, in the real world, sometimes you do have to do it. Often credit card numbers are used to enforce one-per-customer offers. And for good reason -- it's probably the most effective way to do it. However, the cost (insecure data) is too high for the overall business. Slashdot bashing of Marketing be what it may, but if you can explain this to one of the higher ups in the group in an understandable way, as well as work with them to come together with a different solution, they will usually be open to it. Nobody, especially in Marketing, wants to come in one morning, and read on my.yahoo.com that their company?s credit card numbers have been stolen.
Chargebacks have one advantage over credit card abuse: they are not done one the customer?s dime (i.e. nobody is sitting there waiting for a page to load). Most likely it will be possible to queue them together, and use the first and last four digits to limit the sets of rows to be examined, and then simply start decrypting and comparing. None of the intermediate results, obviously, should be shown. This should ONLY allow to get the customer name, etc. from a valid credit card number. That normal caveats of web development apply here as well, despite it being an internal application.
10) Work with your Operations team to test the system. If you breach the zone, are there traces? If you scp off the private key, was that correctly detected as well. Remember the old scare stories of people who never tested their backup system until they needed them, only to find out they didn?t work. Make sure everything here is working as expected.
Anyway, that's all about I can bear to write for now. Hope that helps someone.
-Bill
SlashSig Karma: Excellent (mostly affected by moderatio