You can always degrade the credit card.

1) verify AUTH ONLY (not capture) with your CC provider. (if you want to verify they 
have funds available and the CC is valid)
2) store the CC # in the database 
3) ..do your order processing thing or whatever you need to have the CC for...
4) capture funds 
5) degrade card value in the DB

That seems to work well for non recurring credit card transactions (ie single 
purchases)

Bill "Elvis" Gibbs
goEbusiness.com - putting e-motion in your business
email - [EMAIL PROTECTED] work - 301-668-5090 cell - 301-748-6938

On Wed, 25 Jul 2001, Steve Brazill wrote:

> AND,  you'd want to 'protect' the data from viewing if you've 'dumped' the
> database or backed it up to an 'insecure' media or location (to
> tape/disk)...   Encrypting the data,  with the 'key' or 'salt' located
> somewhere else, would allow you to 'transport' the tables containing the
> sensitive data (i.e. credit card info) with some sense of security...
> 
> ----- Original Message -----
> From: "Fletcher Sandbeck" <[EMAIL PROTECTED]>
> To: "mysql" <[EMAIL PROTECTED]>
> Sent: Wednesday, July 25, 2001 3:08 PM
> Subject: Re: mysql and credit cards
> 
> 
> > On 7/25/01 at 7:12 PM, Alexander Skwar wrote:
> >
> > > However, if you need to reconstruct it, nothing is safe.  And that's
> > > quite simple:
> > > a) You need to get access to the MySQL server.  Impossible to do from
> > > the outside if '--skip-networking' is used.
> > > b) So, only possible from the localhost.  This means, there must have
> > > been a break in to the MySQL server.  Once he's on the server, he can do
> > > anything he likes.  He can also read the source code of your PHP/PERL
> > > pages.  There the password will be stored, somewhere.  Once the password
> > > has been found (which is nothing but a matter of time), your encryption
> > > is broken.
> >
> > I respectfully disagree with this assessment.  Encrypting data in a
> database can be useful, even if the key is relatively easy to find.
> >
> > The situation you describe is one of a determined individual trying to
> gain access to credit card data.  This is indeed the most difficult type of
> person to prevent gaining access to your data.  If they are able to
> compromise your system then they will be able to decrypt the data in the
> database and get the credit card numbers.
> >
> > However, encryption prevents casual viewing of credit card data and
> prevents the discovery of credit card data if a secondary system is
> compromised.
> >
> > For casual viewing, you may have employees who have access to the database
> for the purpose of fulfilling orders or contacting customers.  If credit
> card numbers are encrypted then the employees will have to take a positive
> step to steal credit card numbers.  They won't be able to simply jot down
> numbers out of the data they have available.
> >
> > For example, if an individual gains the ability to execute SQL statements
> on your server, but doesn't have file access.  If the credit card numbers
> are stored plain then they can gain access to them.  If they are stored
> encrypted then the data is of no use without the key.
> >
> > > So, overall, I'd say: Don't hassle with encryption: It's not worth it.
> >
> > I would counter that symmetric encryption is reasonably easy to implement
> and provides a modicum of security, so why not go ahead and do it.  Just
> don't be fooled that a determined individual won't be able to defeat your
> encryption.
> >
> > It's rather like HTTPS encryption.  It's a first step that prevents casual
> peeking at the data which is being transmitted between a client and the
> server.  However, it does not prevent a determined individual from seeing
> the traffic.
> >
> > [fletcher]
> >
> > --
> > Fletcher Sandbeck                         [EMAIL PROTECTED]
> > Lasso Product Specialist                   [EMAIL PROTECTED]
> > Blue World Communications, Inc.         http://www.blueworld.com/
> >
> > ---------------------------------------------------------------------
> > Before posting, please check:
> >    http://www.mysql.com/manual.php   (the manual)
> >    http://lists.mysql.com/           (the list archive)
> >
> > To request this thread, e-mail <[EMAIL PROTECTED]>
> > To unsubscribe, e-mail
> <[EMAIL PROTECTED]>
> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
> >
> 
> 
> ---------------------------------------------------------------------
> Before posting, please check:
>    http://www.mysql.com/manual.php   (the manual)
>    http://lists.mysql.com/           (the list archive)
> 
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
> 
> 



---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to