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
