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). The numbers are then decrypted and
batch processed. The decrypted cc numbers and private key are *never*
stored anywhere on the server except in memory.

I'm sure it's not as secure as having a separate db server behind a
firewall with hardware encryption etc etc, but it works on shared
hosting and is every bit as secure as PGP, but without the huge cost.
We're selling the tag for US$49 (http://www.developer.perthweb.com.au),
and it doesn't require any other software.

Contact me offlist if you have any questions.

Regards,
Kay.


"Don Vawter" <[EMAIL PROTECTED]> wrote in message
news:<098f01c16ee1$f8211860$6501a8c0@LAPTOP>...
> I don't WANT to store credit card information. The question is whether

> the customer is willing to reenter cc number every month.  The billing

> is monthly but unlike a subscription the charge is not constant which 
> seems to be difficult for the providers to handle. Currently I use 
> payflow from Verisign (cfm app by the way) and am perfectly happy with

> them. I am just afraid in this new scenario that a B2B customer is 
> unlikely to be happy filling in cc info every month. Any better 
> solutions would be very welcome. I could even go the paper invoicing 
> method if necessary but that seems terribly inefficient.
> 
> 
> ----- Original Message -----
> From: "BILLY CRAVENS" <[EMAIL PROTECTED]>
> To: "CF-Talk" <[EMAIL PROTECTED]>
> Sent: Friday, November 16, 2001 1:07 PM
> Subject: Re: Best practices storing CC
> 
> 
> > <cf_cya>
> >     I would strongly recommend against storing credit card numbers
> anywhere.
> >     1. potential for thousands, if not millions, in dollars of
liability
> >     2. if the site's customers find out, they will likely go 
> > somewhere
> else
> > (I do when I know a site stores my card #)
> >     3. performance - CF's encryption is too weak - you'd need to use

> > something third-party which would probably be a load increase
> >     4. see #1
> >     5. see #4
> >     6. see #5
> > </cf_cya>
> >
> > However, if you just HAVE to keep your users from reentering their 
> > card # every time, look at some third party solutions.  Microsoft's 
> > comes to
> mind.
> > (Okay ppl - let's pretend like we're mature and not turn this into 
> > another pathetic "why Microsoft is bad thread" - I'm just pointing 
> > out a potential
> > technology)  I don't know how much faith I have in other company's
> security
> > infrastructures, but I'd be willing to bet that it's far better than

> > anything that I could ever hope to build.
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Don Vawter" <[EMAIL PROTECTED]>
> > To: "CF-Talk" <[EMAIL PROTECTED]>
> > Sent: Friday, November 16, 2001 1:46 PM
> > Subject: Best practices storing CC
> >
> >
> > > Any advice on storing credit card info?
> > >
> > >
> > > My thoughts are that it should be stored in a separate db which is

> > > not accessible via web and have cf push the info to a template 
> > > behind the firewall to do the
> > actual
> > > authorization and push the results back to the main server. Does 
> > > this
> make
> > > sense or am I making it too complicated (or leaving something 
> > > obvious
> > out).
> > >
> > > What are recommendatsions on encyption, is DES ok or do I need 
> > > something else?
> > >
> > > TIA
> > >
> > > Don
> > >
> > 
> 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to