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/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
