But what happens when the customer returns the product? You no longer
have the cC to do a chargeback
On Wed, 25 Jul 2001, Elvis wrote:
> Date: Wed, 25 Jul 2001 20:53:26 -0400 (EDT)
> From: Elvis <[EMAIL PROTECTED]>
> To: Steve Brazill <[EMAIL PROTECTED]>
> Cc: Fletcher Sandbeck <[EMAIL PROTECTED]>,
> mysql <[EMAIL PROTECTED]>
> Subject: Re: mysql and credit cards
>
> 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
>
Sincerely,
William Mussatto, Senior Systems Engineer
CyberStrategies, Inc
ph. 909-920-9154 ext. 27
---------------------------------------------------------------------
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
