All, I just wanted to thank all of you for giving this thread some attention. After a little more research and phone calls today to payment gateways, I believe I have found the answer to my original question. It appears that Authorize.Net allows for recurring payments "without" the credit card number having to be passed every time to the gateway. Therefore, I should be able to completely bypass the storing of credit card numbers, which is a huge relief. I am sure all of the other payment gateways do this, too, but Authorize.net is the one I am going to use.
Here is the information from their Developer's Guide that sums up the solution.... --- From Dev Guide --- Batch processing Aside from the automated ways of integrating with the system, batches of transactions can be uploaded to the system for processing. All transactions contained in the uploaded file are processed in the currently open batch and are settled with any other transactions pending in that same batch. One way this capability can be useful is for merchants who collect their transaction information over the course of the day, and want to upload their transactions for processing all at one time. This capability can also be useful for merchants who have recurring transactions, such as monthly subscription fees. Each month a merchant could upload a file containing all of their customers' transaction information to bill their customers for another month. In addition to being able to upload batches of transactions, the system allows a merchant to download settlement batches as a file to their own computer. --- End Dev Guide --- The encryption information you all provided was both informative and useful for another piece of this project. Thanks again for the help, Jeff Stone Stone Grove Design [EMAIL PROTECTED] -----Original Message----- From: Kwang Suh [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 8:36 AM To: CF-Talk Subject: Re: Storing Credit Cards What are the other solutions then? I agree PGP isn't the only solution. ----- Original Message ----- From: "Dave Hannum" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Friday, October 05, 2001 5:48 AM Subject: Re: Storing Credit Cards > I'm not trying to say that there is anything wrong with PGP (other than the > exhorbatant commmercial price) - all I was saying was that if done properly > (which all of your arguements against what I have proposed have assumed that > sloppy handling of the process is taking place) - there are other solutions > that will be reasonably secure. Face it - any credit cards stored on a > server are NEVER SAFE! That's been talked about here time and time again. > > Dave > > ----- Original Message ----- > From: "Kwang Suh" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Thursday, October 04, 2001 11:36 PM > Subject: Re: Storing Credit Cards > > > > Oh yes. I need to add one more thing. No matter how smart you think you > > are, any form of encryption you come up with will suck. It doesn't matter > > how many steps of obfuscation or whatever you put in. It will still suck. > > I used to work with a guy who was a decent cryptography programmer. He > says > > that there are very, very, very few people in the world who can write > decent > > encryption schemes. No offense, but no one on this list is qualified to > > write encryption schemes. No one on this list should even have the > smallest > > spark of thinking of thinking of writing an encryption scheme. Use > someone > > else's. > > > > ----- Original Message ----- > > From: "Kwang Suh" <[EMAIL PROTECTED]> > > To: "CF-Talk" <[EMAIL PROTECTED]> > > Sent: Thursday, October 04, 2001 9:23 PM > > Subject: Re: Storing Credit Cards > > > > > > > Because, in order to do a valid CC transaction, one needs: > > > > > > Name > > > Address > > > CC# > > > Expiry Date > > > > > > So, if you had a database table with say, Name, Address, CC#(encrypted), > > > Expiry Date(encrypted), do you think your system is secure? Nope. > > > > > > So, let's move the Name and Address somewhere else. But, it's gotta be > > > somewhere where CF can reach it. Also, the key's gotta be somewhere > where > > > CF can reach it (remember, this guy needs to do automated recurring > > > transactions). If CF can reach it, there is the (slight, very slight) > > > chance that a hacker can reach it. Can you live with the risk? > Depends. > > > > > > And yes, people do in fact brute force create valid CC numbers. CC > fraud > > is > > > vast. Unbelievably vast. There is so much fraud out there, it's > > > ridiculous. Why do you think AMEX created one use CC numbers? Why do > new > > > CCs have a 3 digit append number in addition to to the CC number? Why > do > > CC > > > companies charge more for e-vendors? > > > > > > The BEST way to encrypt is via a mechanism that uses a Public > Key/Private > > > Key combination in conjunction with a highly random passphrase that > > contains > > > multiple non-alphanumeric characters. Something like Triple-DES is > always > > > nice to have. > > > > > > There's a decent book out there that talks about this sort of stuff. > It's > > > called Cryptography and E-Commerce by Jon C. Graff. Nice primer on this > > > sort of stuff. > > > > > > ----- Original Message ----- > > > From: "Dave Hannum" <[EMAIL PROTECTED]> > > > To: "CF-Talk" <[EMAIL PROTECTED]> > > > Sent: Thursday, October 04, 2001 11:05 AM > > > Subject: Re: Storing Credit Cards > > > > > > > > > > OK - while we're on the topic. You state . . .that CC numbers have > > > patterns > > > > in them that drastically reduce the number of valid resultsets . . . > why > > > not > > > > use brute force to just churn out a bunch of valid credit card numbers > > and > > > > use them ???? > > > > > > > > If you munge (encrypt) the cc numbers with a key - displace the owner > > name > > > > and the expiration date in various locations, why would that be any > less > > > > secure??? > > > > > > > > Educate me here . . . > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Kwang Suh" <[EMAIL PROTECTED]> > > > > To: "CF-Talk" <[EMAIL PROTECTED]> > > > > Sent: Thursday, October 04, 2001 12:34 PM > > > > Subject: Re: Storing Credit Cards > > > > > > > > > > > > > I should point out that this is a very simple form of encryption > (call > > > it > > > > > whatever you want, it's still encryption), and EASILY hackable. How > > > long > > > > do > > > > > you think it would take a computer to do brute-force key calculation > > on > > > > such > > > > > a simple key, especially considering that CC numbers have patterns > in > > > them > > > > > that drastically reduce the number of valid resultsets? Maybe a > > couple > > > of > > > > > seconds at most? > > > > > > > > > > To the original poster: > > > > > > > > > > PGP is VERY hard to crack. Especially with a large key, such as > > > 1024-bit. > > > > > Certainly, the amount of time that it would take to crack the key is > > > > greater > > > > > than the usefulness of the information (e.g. by the time your hacker > > got > > > > the > > > > > CC number, the person who owned the CC would have died of old age). > > > > > > > > > > Look into GPG. It's free, and you can use CFEXECUTE to run the GPG > > > > > encrption/decryption executable (doing it this way prevents you from > > > > > releasing your source code under the GPL, as you're just _using_ > GPG, > > > not > > > > > modifying it :). > > > > > > > > > > ----- Original Message ----- > > > > > From: "Dave Hannum" <[EMAIL PROTECTED]> > > > > > To: "CF-Talk" <[EMAIL PROTECTED]> > > > > > Sent: Thursday, October 04, 2001 10:04 AM > > > > > Subject: Re: Storing Credit Cards > > > > > > > > > > > > > > > > Just FYI - it's a fact. Munging the credit card numbers is harder > > to > > > > > crack > > > > > > than encryption. > > > > > > For example. You have a key. You add a documented value to the > > first > > > > set > > > > > > of four numbers and add another number to the second set of four > > > > numbers. > > > > > > (dummy cc number here) > > > > > > > > > > > > Visa 4563 2784 9001 2483 > > > > > > > > > > > > Add Key 1 = 4321 > > > > > > Add Key 2 = 9876 > > > > > > > > > > > > Store number as 8884 12660 9001 2483 > > > > > > > > > > > > Without the keys, this number is impossible to crack. > > > > > > > > > > > > You store your key. Then, when you want to process again, you > > > subtract > > > > > the > > > > > > numbers you added in and you have a valid credit card number. As > > > long > > > > as > > > > > > that key is not web accessable, you're secure. VERY secure. And > > much > > > > > > cheaper than PGP. > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Megan Cytron" <[EMAIL PROTECTED]> > > > > > > To: "CF-Talk" <[EMAIL PROTECTED]> > > > > > > Sent: Thursday, October 04, 2001 11:28 AM > > > > > > Subject: RE: Storing Credit Cards > > > > > > > > > > > > > > > > > > > I have also done this using CFX_PGP. In our case, we FTPed the > > > > > > > order and PGP-encrypted CC info to a Unix server and they moved > > > > > > > the file to a secure location behind a firewall and deleted it > > > > > > > from the FTP folder. You could also do this via VPN. > > > > > > > > > > > > > > Another question: has anyone found any shared hosts that support > > > > > > > CFX_PGP? > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Megan > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > Alpha 60 Design Shop > > > > > > > http://www.alpha60.com > > > > > > > phone: 202-745-6393 > > > > > > > fax: 202-745-6394 > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Alex Santantonio [mailto:[EMAIL PROTECTED]] > > > > > > > > Sent: Thursday, October 04, 2001 11:22 AM > > > > > > > > To: CF-Talk > > > > > > > > Subject: RE: Storing Credit Cards > > > > > > > > > > > > > > > > > > > > > > > > If you must store credit card info, it might be a good > > > > > > > > idea to follow some > > > > > > > > of these steps in addition to the typical Secure > > > > > > > > Certificate and so on. You > > > > > > > > should absolutely encrypt them using PGP or some other > > > > > > > > type of encryption. > > > > > > > > I have used CF_PGP on several clients and it works > > > > > > > > quite well. You could > > > > > > > > probably use some sort of ASP PGP COM object with CF > > > > > > > > instead of paying the > > > > > > > > $400 for CF_PGP. In addition to this, you can also > > > > > > > > create an automated > > > > > > > > process that will transfer the card numbers from the > > > > > > > > live database to > > > > > > > > another database that is not accessible through the > > > > > > > > site in any way. Then > > > > > > > > write the good old xx*****xxxx to the live database > > > > > > > > for future management. > > > > > > > > Then you can transfer your billing software that you > > > > > > > > write to actually > > > > > > > > charge the cards on the schedule behind this secure > > > > > > > > section so only people > > > > > > > > within the office or from a certain IP address can > > > > > > > > process cards. This will > > > > > > > > at least make it much more difficult to get at this > > > > > > > > data, and if your > > > > > > > > database is hacked or stolen from your live site, the > > > > > > > > only cards that might > > > > > > > > even be in there would be the ones that were not yet > > > > > > > > transferred, and those > > > > > > > > would be encrypted in PGP so it would take someone a > > > > > > > > good deal of time to > > > > > > > > get at it that way. So in short. > > > > > > > > > > > > > > > > 1. Store credit cards PGP encrypted in the database > > > > > > > > 2. Transfer on a schedule and store them in a separate > > > > > > > > Database with the > > > > > > > > info on the live database overwritten > > > > > > > > 3. Move billing management behind a firewall or some > > > > > > > > server that is no way > > > > > > > > accessible to the outside. > > > > > > > > > > > > > > > > This should at least minimize your risk a bit. > > > > > > > > > > > > > > > > Alex Santantonio > > > > > > > > Lead Developer > > > > > > > > Macromedia Coldfusion 5 Certified Professional > > > > > > > > Macromedia Certified Web Site Developer > > > > > > > > [EMAIL PROTECTED] > > > > > > > > www.doceus.com > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jeff Stone [mailto:[EMAIL PROTECTED]] > > > > > > > > Sent: Thursday, October 04, 2001 10:55 AM > > > > > > > > To: CF-Talk > > > > > > > > Subject: Storing Credit Cards > > > > > > > > > > > > > > > > I am hoping that someone in this group may be able to > > > > > > > > help me. The company > > > > > > > > I work for is building a service-based ecommerce > > > > > > > > website. Because this site > > > > > > > > sells website space to other customers, I need to > > > > > > > > charge these customers > > > > > > > > monthly for the services we are providing. Therefore, > > > > > > > > I believe I am going > > > > > > > > to have to store the customer's credit card numbers in > > > > > > > > order to charge their > > > > > > > > cards every month for their continued use of our services. > > > > > > > > > > > > > > > > I have done quite a few product-based ecommerce sites > > > > > > > > in the past and have > > > > > > > > never had to face this issue. In the past, I have > > > > > > > > used Cybersource and > > > > > > > > Cybercash passing them the user's credit card > > > > > > > > information at the time of > > > > > > > > purchase and then just storing the authorization code > > > > > > > > that was returned in > > > > > > > > my database. Then, when the products were shipped, I > > > > > > > > would pass the > > > > > > > > authorization code back to Cybersource and they would > > > > > > > > give me a billing code > > > > > > > > that would confirm that a request for the card to be > > > > > > > > charged had been > > > > > > > > completed. This was very secure because I never had > > > > > > > > to store the credit > > > > > > > > card numbers at all. The only problem is that these > > > > > > > > authorization codes are > > > > > > > > only good for 7-10 days, so I cannot use this same > > > > > > > > process for my current > > > > > > > > customer. > > > > > > > > > > > > > > > > I know there are a lot of people out there currently > > > > > > > > storing credit cards. > > > > > > > > I know all of the ISPs must be doing it to be able to > > > > > > > > constantly charge my > > > > > > > > credit card each month. Has anyone done this before, > > > > > > > > and if so, how? I > > > > > > > > have spent the last couple of days looking for the best > > > > > > > > encryption/decryption scheme, but at the sore lack of > > > > > > > > information that I > > > > > > > > have found, I thought I would turn to this group for > > > > > > > > some advice (assuming > > > > > > > > that someone out there must have the answer). I would > > > > > > > > also be interested in > > > > > > > > knowing if anyone is aware of a third party clearing > > > > > > > > house or payment > > > > > > > > processor that can provide a very secure credit card > > > > > > > > storage service. As > > > > > > > > you can tell, I am very hesitant to want to store > > > > > > > > these credit card numbers > > > > > > > > at all. > > > > > > > > > > > > > > > > Any help you all may be able to give would be much > appreciated. > > > > > > > > > > > > > > > > Thanks again, > > > > > > > > > > > > > > > > Jeff Stone > > > > > > > > Stone Grove Design > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
