How about encrypting the credit card with a secret word that the user
chooses? Or obsfucate it by encrypting their credit card using
str_rot13(base64_encode(str_rot13($lastname).$lastname.$email.$firstname))
as the key? Sure, if someone gets your code and your DB, those credit card
numbers are as good as gone. But what about using a C program, stripped,
doing the same thing? That way even if they get your PHP code AND the C
program, they won't be able to reverse engineer the code. They can,
however, start plugging in strings into the C program (if they have the
same system you have, binary compatibility and all) and try those outputted
strings on the DB.
Let's all agree though: there is no 100% sure way to protect any data if
you are going to be able to decrypt it.
There are ways, however, to make it tough to do so for the average hacker.
I mean, if Hacker A wants your credit cards, you can't keep the key from
them. You have to use it somehow to encrypt it, and assuming this happens
in the code and not manually, it is located somewhere on your site. If
they can get the DB, they can get the key.
Obsfucation always worked for me.
Peter
On Wed, 23 Oct 2002, Aaron Wolski wrote:
> Maybe you do,
>
> Bt I run a _client_dictates_the_development_requirments business. It not
> not be that expensive but to some clients who are trying to give it a go
> it can mean a lot.
>
> Am I to tell them I won't accept their business? No - what I am to do is
> provide them with the best alternative which is storing the encrypted
> credit card info until it has been downloaded then wipe it from the
> system. Perfect? Hell no but a solution nonetheless.
>
> I'm not arguing that we shouldn't be storing credit card info -
> encrypted or otherwise - but sometimes life and business just isn't
> perfect. I would rather develop a solution like this for them instead of
> them going to some hack who could give 2 shits about security.
>
> My clients dictate the development and I provide the expert and
> cautionary advive. If they are willing to be obtuse about the process
> then who I am to balk?
>
> Just my thoughts.
>
> Aaron
>
>
> P.S. Cheap shot comments like that of yours serve no purpose for
> learning here.
>
>
> -----Original Message-----
> From: 1LT John W. Holmes [mailto:holmes072000@charter.net]
> Sent: Wednesday, October 23, 2002 4:41 PM
> To: aaronjw@martekbiz.com; 'Ryan Jameson (USA)'; php-db@lists.php.net
> Subject: Re: Credit Card Info & Cryptography
>
>
> > Well.. Isn't that the ideal.
> >
> > I agree in theory, however, not all clients are willing to shell for
> > the Payment Processor Services if they are just starting ou tin
> > e-commerce and don't know what kind of volume to expect.
>
> They aren't that expensive and usually come with all of the scripts you
> need to implement it.
>
> > Thery is wonderful, however, practicle must preside.
>
> Hmmm, that's funny. I would think that _security_ must preside. Maybe I
> run a different business than you do.
>
> ---John Holmes...
>
> > -----Original Message-----
> > From: 1LT John W. Holmes [mailto:holmes072000@charter.net]
> > Sent: Wednesday, October 23, 2002 4:33 PM
> > To: Ryan Jameson (USA); php-db@lists.php.net
> > Subject: Re: Credit Card Info & Cryptography
> >
> >
> > When ever I see "easy", "encrypt", and "credit card" in the same
> > sentence, it makes me worry.
> >
> > Don't store credit card numbers. Charge them once and don't save it
> > anywhere.
> >
> > ---John Holmes...
> >
> > ----- Original Message -----
> > From: "Ryan Jameson (USA)" <RJameson@usa.ibs.org>
> > To: <php-db@lists.php.net>
> > Sent: Wednesday, October 23, 2002 4:20 PM
> > Subject: RE: Credit Card Info & Cryptography
> >
> >
> > Since your goal is to encrypt the card number in the database you'll
> > naturally need a way to decrypt it as well. At that point it seems
> > your concern is that your database will be compromised. That can be
> > avoided easily by creating a single private key and using your own
> > algorithm to encrypt based on that key. The only catch is, if the code
>
> > that does the encrypting is compromised, and the database is
> > compromised, then the numbers are compromised. My basic point is, your
>
> > need is not the same as what PGP addresses in that PGP addresses the
> > more difficult problem of passing data between 2 entities. Your
> > requirement is very simple to address; 1. write a simple compiled
> > module with an embedded key, 2. keep that key in a safe place, and 3.
> > write another module to decrypt, all it needs is the key. This is
> > similar to what was done with DVDs, just don't allow your encryption
> > algorithms to be compromised. You can put the source code in the same
> > place as your key, you can use a code scrambler when you compile, and
> > you should already have your server secure already. Again, my point
> > is, this is easy because the same entity that encrypts is doing the
> > decrypt. Hope this helps.
> >
> > <>< Ryan
> >
> > -----Original Message-----
> > From: Doaldo Navai Junior [mailto:doaldo@triunfo-bsb.com.br]
> > Sent: Wednesday, October 23, 2002 12:53 PM
> > To: php-db@lists.php.net; php-general@lists.php.net
> > Subject: Credit Card Info & Cryptography
> >
> >
> > Suppose I sell some products online and get user's credit card info
> > via SSL connection. Isn't there any method (free, preferably) of
> > ASSYMETRIC (Public
> > key) cryptography I can use with PHP to store this data in a db?? Or
> > is there any other good option instead of this?
> >
> > TIA,
> > Doaldo
> >
> >
> >
> > --
> > PHP Database Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > --
> > PHP Database Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > --
> > PHP Database Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > --
> > PHP Database Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
---------------------------------------------------------------------------
Peter Beckman Systems Engineer, Fairfax Cable Access Corporation
beckman@purplecow.com http://www.purplecow.com/
---------------------------------------------------------------------------
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
