been silent on this one :) I have considered implementing something for the wonderful CFWEBSTORE that we use as a base for our commerce implementations...
some ground rules for whatever you use: 1. Store CC number + expiration + name in encrypted format... any one of the three fields got in plain text could be the start of compromising the rest... 2. Ideally, the password, keypad used to create the encryption schema shouldn't be found in plain text anywhere on your server. 3. Your decryption key/password should change with some regularity and be unique to each client. 4. Any swap spaces (disk) that is used to encrypt stuff should be routinely wiped of data and overwritten to make recovery impossible. As far as the encryption methodology, the RSA has proven itself to be some of the best stuff widely used to date. If you can buy the base technology and implementation at a price you/client can afford. IN the case of monthly renewals... If the cycle is set to auto-rebill, store the key yourself and have someone type it in while connected via SSL to the server as a monthly task.... If the renewal requires authorization each month from the card holder, create a form-based solution for the customer... Pull a faked TRANSACTION identifier that identifies the person/last transaction. Get a Yes or No from them to rebill... Ask them if they want to use the credit info you have on file... then have it added to a nightly batch or in the case of live time, you would have to store your pad in server's memory .... Recommend a daily batch job ran by administrator with the pad.... Ideally, with one set of keys the operator controls the show... with truly encrypted data, if a key is lost there is no data... :) Been through the consideration of this sort of solution for a while. Never found the real need in my world to implement it... Will be glad to share more with greater details provided by anyone. I believe that these sorts of subsystems will become mandatory shortly for anyone taking transactions involving banking info online. -paris -----Original Message----- From: Don Vawter [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 18, 2001 22:55 To: CF-Talk Subject: Re: Best practices storing CC I don't think client and customer are the same Jim. I think by client she is referring to the site owner who goes in once a month to process the cards of his customers. ----- Original Message ----- From: "Jim McAtee" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, November 18, 2001 8:42 PM Subject: Re: Best practices storing CC > ----- Original Message ----- > From: "Kay Smoljak" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Sunday, November 18, 2001 8:28 PM > Subject: Re: Best practices storing CC > > > > Hi Don, > > > > Warning: this email does contain a plug... > > > > We had a similar problem with a client who has a subscription site. We > > created a custom tag - CFX_PWCARDCRYPT, which encrypts the number using > > a 512, 1024 or 2048 bit RSA public key, which can safely be stored on > > the server. To process the payments each month, the client goes to an > > SSL page and enters his private key, which is only stored offline on his > > personal computer (we even recommend it's stored on a floppy disk in his > > safe, rather than on his machine). > > > Somehow, that sounds like a lot more work for the customer than simply > reaching into his or her wallet, grabbing the CC and re-entering the number. > > Jim > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
