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
