Another option would be to use an asymmetric encryption method alongside the
process you described before. For this you use a public key stored on the
server, but to decrypt the credit card number the operator needs to type in
a private key. As this key is not stored on the server there is no security
risk. You would then of course have to store the numbers twice, one
encrypted with the user password, and one encrypted with the public/private
key pair.
----- Original Message -----
From: "Tony Schreiber" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Saturday, May 05, 2001 2:14 AM
Subject: Re: Credit Card DB Encryption Methodology
> Ok, I've been thinking about this. And in the case of returns or credits,
> I think we could this:
>
> On the website as the customer requests a return, they must enter their
> password. I store this encrypted with the RMA number (or some other
> associated id) as the key. Once the return is processed, the server uses
> the RMA number to decrypt the password to decrypt the CC info and process
> the credit...
>
> Now I've comprised the security of those users with pending returns, but
> that would be a small percentage of users at any given time. And if I'm
> going to use an easily available key to encrypt the password temporarily,
> it's almost not even worth the bother...
>
> Still thinking.
>
> OR, I would have to request the customer to login to the website and check
> if their return has been received, then enter their password when prompted
> in order to receive the credit.
>
> Another issue is that I'm locked to doing ONLY real-time processing. If
> the cc processing gateway is down, I can't take orders...
>
> > So what are you doing in those cases, do you have to contact the
customer?
> > Curious...
> >
> > > > I thought the reason most people kept card numbers around was
> > > > for handling credits, delayed charges, and other problems (or
> > > > possibly because of record-keeping requirements of their bank),
> > > > or because they're doing the credit card charges manually (or
> > > > at least with some human intervention) rather than in real
> > > > time. It doesn't seem like your solution would work in that
> > > > situation.
> > >
> > > Correct, that wouldn't work here, because we don't have an unecrypted
> > > version of the user's password available.
> > >
> > > > Keith C. Ivey <[EMAIL PROTECTED]>
> > > > Webmaster, EEI Communications
> > >
> > >
> > >
> > > Tony Schreiber, Senior Partner Man and Machine,
Limited
> > > mailto:[EMAIL PROTECTED]
http://www.technocraft.com
> > >
> > > http://www.simplemessageboard.com ___Free Forum Software for Cold
Fusion
> > > http://www.is300.net ___________The Enthusiast's Home of the Lexus
IS300
> > > http://www.digitacamera.com ______________DigitA Camera Scripts and
Tips
> > > http://www.linklabexchange.com _____________Miata Link ECU Data
Exchange
> > >
> > >
> > >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
