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] > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm 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
