Credit Card Encryption

Hi Everyone,

I'm trying to determine the best method to store credit card numbers in a
mysql database. As yet I have been unable to determine whether I should use
MySQL AES, DES or a PHP encryption method. I would greatly appreciate any
advice you guys could offer.

Thanks.

Keith

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Credit Card Encryption

Keith Spiller wrote:
> Hi Everyone,
>
> I'm trying to determine the best method to store credit card numbers in
> a mysql database. As yet I have been unable to determine whether I
> should use MySQL AES, DES or a PHP encryption method. I would greatly
> appreciate any advice you guys could offer.

Why do you need to store c/c info? If at all possible, don't.

If you're looking for something like recurring payments, use paypal or
one of the other payment providers that support it.


--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Credit Card Encryption

And if you do store it, don't store it on the websderver. Make sure it's on another server behind another firewall.

You don't want someone that hacks into your web server to have ready access to your database.

I think AES is supposed to be the best, then 3DES is next. (That's 3DES, or triple DES, not DES)

But like Chris said: if you don't have to, dont do it.

But if you must, encrypt all of the personal information data points, not just the CC info.

Gary

> -----Original Message-----
> From: Chris [mailto:dmagick@gmail.com]
> Sent: Tue, December 18, 2007 9:30 PM
> To: Keith Spiller
> Cc: php-db@lists.php.net
> Subject: Re: [PHP-DB] Credit Card Encryption
>
>
> Keith Spiller wrote:
> > Hi Everyone,
> >
> > I'm trying to determine the best method to store credit
> card numbers in
> > a mysql database. As yet I have been unable to determine whether I
> > should use MySQL AES, DES or a PHP encryption method. I
> would greatly
> > appreciate any advice you guys could offer.
>
> Why do you need to store c/c info? If at all possible, don't.
>
> If you're looking for something like recurring payments, use
> paypal or
> one of the other payment providers that support it.
>
>
> --
> Postgresql & php tutorials
> http://www.designmagick.com/
>
> --
> 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

RE: Credit Card Encryption

--_12cde5bb-c50d-4870-870f-0ac744e6a981_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Think very carefully about what you want to do here. PCI (payment card indu=
stry) has radically changed the rules about how CC data is stored in a netw=
orked environment. If your data environment is shared (shared web hosting),=
don't even think about it. There are a large number of rules that you need=
to follow to make your data systems PCI compliant [ http://www.pcicomplian=
ceguide.org/ ] and they are not easy to follow. Things like strong encrypti=
on, code audits by qualified third parties etc.
=20
If you absolutely need to store the data (many of my large clients do this)=
:
1. the database server should not be web facing, nor accessible internally =
by the web servers
2. the access (physical and electronic) should be extremely limited
3. the facility that holds the data should be hardened with limited control=
led access
4. provide a cross reference number to the CC that other applications can u=
se to replace the CC number
=20
If you are storing transactional data, just store the confirmation number t=
hat is returned by the payment gateway that you use. Let the payment gatewa=
y assume the risks of handling the data, its what they get paid for. If the=
data is for re-occurring payments, let the payment gateway handle it, many=
support these kinds of payments.
=20
Bastien
> From: larentium@hosthive.com> To: php-db@lists.php.net> CC: larentium@hos=
thive.com> Date: Tue, 18 Dec 2007 18:20:08 -0700> Subject: [PHP-DB] Credit =
Card Encryption> > Hi Everyone,> > I'm trying to determine the best method =
to store credit card numbers in a > mysql database. As yet I have been unab=
le to determine whether I should use > MySQL AES, DES or a PHP encryption m=
ethod. I would greatly appreciate any > advice you guys could offer.> > Tha=
nks.> > Keith > > -- > PHP Database Mailing List (http://www.php.net/)> To =
unsubscribe, visit: http://www.php.net/unsub.php>=20
____________________________________________________________ _____
Discover new ways to stay in touch with Windows Live! Visit the City @ Live=
today!
http://getyourliveid.ca/?icid=3DLIVEIDENCA006=

--_12cde5bb-c50d-4870-870f-0ac744e6a981_--

Re: Credit Card Encryption

------=_NextPart_000_016F_01C841D0.77AA4670
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks for the information, especially the PCI Complancy link and info.

Keith
----- Original Message -----=20
From: Bastien Koert=20
To: Keith Spiller ; php-db@lists.php.net=20
Sent: Tuesday, December 18, 2007 9:41 PM
Subject: RE: [PHP-DB] Credit Card Encryption


Think very carefully about what you want to do here. PCI (payment card =
industry) has radically changed the rules about how CC data is stored in =
a networked environment. If your data environment is shared (shared web =
hosting), don't even think about it. There are a large number of rules =
that you need to follow to make your data systems PCI compliant [ =
http://www.pcicomplianceguide.org/ ] and they are not easy to follow. =
Things like strong encryption, code audits by qualified third parties =
etc.
=20
If you absolutely need to store the data (many of my large clients do =
this):
1. the database server should not be web facing, nor accessible =
internally by the web servers
2. the access (physical and electronic) should be extremely limited
3. the facility that holds the data should be hardened with limited =
controlled access
4. provide a cross reference number to the CC that other applications =
can use to replace the CC number
=20
If you are storing transactional data, just store the confirmation =
number that is returned by the payment gateway that you use. Let the =
payment gateway assume the risks of handling the data, its what they get =
paid for. If the data is for re-occurring payments, let the payment =
gateway handle it, many support these kinds of payments.
=20
Bastien


> From: larentium@hosthive.com
> To: php-db@lists.php.net
> CC: larentium@hosthive.com
> Date: Tue, 18 Dec 2007 18:20:08 -0700
> Subject: [PHP-DB] Credit Card Encryption
>=20
> Hi Everyone,
>=20
> I'm trying to determine the best method to store credit card numbers =
in a=20
> mysql database. As yet I have been unable to determine whether I =
should use=20
> MySQL AES, DES or a PHP encryption method. I would greatly =
appreciate any=20
> advice you guys could offer.
>=20
> Thanks.
>=20
> Keith=20
>=20
> --=20
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20



------------------------------------------------------------ -------------=
-----
Books, DVD's, gadgets, music and more. Shop online with Sympatico / =
MSN Shopping today!
------=_NextPart_000_016F_01C841D0.77AA4670--

Re: Credit Card Encryption

Ok I've done some research and some thinking. What about storing orders in
the database (product info and customer info) and then using GnuPG or PGP to
send the credit card info to the merchant? This way the credit card
information is not stored on the server or in the database but only in
printed format by the merchant. Since my client processes all of the credit
card orders by hand this seems like an ideal solution.

What is more, the order and customer info do not need to be present in the
encrypted emails. That way the email does not contain a customer name, but
only an order id (which could even be a unique and hidden value stored via
AES in the mysql db).

What are your thoughts?

Keith

----- Original Message -----
From: "Bastien Koert"
To: "Keith Spiller" ;
Sent: Tuesday, December 18, 2007 9:41 PM
Subject: RE: [PHP-DB] Credit Card Encryption



Think very carefully about what you want to do here. PCI (payment card
industry) has radically changed the rules about how CC data is stored in a
networked environment. If your data environment is shared (shared web
hosting), don't even think about it. There are a large number of rules that
you need to follow to make your data systems PCI compliant [
http://www.pcicomplianceguide.org/ ] and they are not easy to follow. Things
like strong encryption, code audits by qualified third parties etc.

If you absolutely need to store the data (many of my large clients do this):
1. the database server should not be web facing, nor accessible internally
by the web servers
2. the access (physical and electronic) should be extremely limited
3. the facility that holds the data should be hardened with limited
controlled access
4. provide a cross reference number to the CC that other applications can
use to replace the CC number

If you are storing transactional data, just store the confirmation number
that is returned by the payment gateway that you use. Let the payment
gateway assume the risks of handling the data, its what they get paid for.
If the data is for re-occurring payments, let the payment gateway handle it,
many support these kinds of payments.

Bastien
> From: larentium@hosthive.com> To: php-db@lists.php.net> CC:
> larentium@hosthive.com> Date: Tue, 18 Dec 2007 18:20:08 -0700> Subject:
> [PHP-DB] Credit Card Encryption> > Hi Everyone,> > I'm trying to determine
> the best method to store credit card numbers in a > mysql database. As yet
> I have been unable to determine whether I should use > MySQL AES, DES or a
> PHP encryption method. I would greatly appreciate any > advice you guys
> could offer.> > Thanks.> > Keith > > -- > PHP Database Mailing List
> (http://www.php.net/)> To unsubscribe, visit:
> http://www.php.net/unsub.php>
____________________________________________________________ _____
Discover new ways to stay in touch with Windows Live! Visit the City @ Live
today!
http://getyourliveid.ca/?icid=LIVEIDENCA006

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Credit Card Encryption

On Dec 19, 2007 2:41 AM, Keith Spiller wrote:
> Ok I've done some research and some thinking. What about storing orders in
> the database (product info and customer info) and then using GnuPG or PGP to
> send the credit card info to the merchant? This way the credit card
> information is not stored on the server or in the database but only in
> printed format by the merchant. Since my client processes all of the credit
> card orders by hand this seems like an ideal solution.

I had a client that did offline (manual) processing of credit card
orders as well. With liability issues and the problems that others
have already pointed out, storing the credit card information was not
an option, yet my client still needed some way of having the data
available offline.

Consider the following:

ISSUER LENGTH
Diner's Club/Carte Blanche 14
American Express 15
VISA 13 or 16
MasterCard 16
Discover 16

Security checks aside (like making sure they selected the type of
card and that it matched the algorithm - VISA beginning with 4 and
being strlen($_POST['cardnum']) == 13 or 16, MasterCard being 16,
beginning with 51xx to 55xx, et cetera), I then had a hybrid of
storage and delivery.

Mail the first digits to the sales email
address(es) on file. Three addresses on two domains were used for
redundancy in this case. Store the remaining digits in the database.
You could write your own encryption algorithm or use one that is
publicly-available and reversible (Blowfish is what I was using, at
128, key length of 56 lower ASCII characters, padded with 7 on the key
and four on the output - MD5, SHA1, et al are NOT options here).

The sales department then received the first digits of the credit
card number via email, which stated it was an order key. Again, in my
case, I wrote an algorithm that would encrypt these digits prior to
sending, using the actual order number as a key. The accounting
software I wrote (all in PHP) would then retrieve the latter half of
the credit card number from the database, decrypt the first part of
the credit card number from the email (entered by the sales team on an
SSL-encrypted page), and the credit card number would be displayed in
full on the screen, to print, process, or verify.

The downside is that, if there are any problems with email and
delivery, the first $n digits of the card might not be received by the
sales department. While, to date, I'm not aware of this having been a
problem for my client (knock on wood), it's still a possibility. For
this reason, you need to be sure to either have the email address
confirmed prior to processing the order, or require a valid telephone
number, so that you can reach the customer in the event of a failure.
To assure the customer that you are calling legitimately, you will
still have the last digits of the credit card, as well as the
expiration data and CVV number (also stored in the database), the
billing address, and the date and time the order was placed.

It may not work for you, but that's how I created the system for
my client in 2004, and it's still being used today, with almost $8
Million in online sales. [pats self on back] ;-P

Now if I could just go back and renegotiate my contract for that gig....

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Credit Card Encryption

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Brown wrote:
> On Dec 19, 2007 2:41 AM, Keith Spiller wrote:
>> Ok I've done some research and some thinking. What about storing orders in
>> the database (product info and customer info) and then using GnuPG or PGP to
>> send the credit card info to the merchant? This way the credit card
>> information is not stored on the server or in the database but only in
>> printed format by the merchant. Since my client processes all of the credit
>> card orders by hand this seems like an ideal solution.
>
> I had a client that did offline (manual) processing of credit card
> orders as well. With liability issues and the problems that others
> have already pointed out, storing the credit card information was not
> an option, yet my client still needed some way of having the data
> available offline.
>
> Consider the following:
>
> ISSUER LENGTH
> Diner's Club/Carte Blanche 14
> American Express 15
> VISA 13 or 16
> MasterCard 16
> Discover 16
>
> Security checks aside (like making sure they selected the type of
> card and that it matched the algorithm - VISA beginning with 4 and
> being strlen($_POST['cardnum']) == 13 or 16, MasterCard being 16,
> beginning with 51xx to 55xx, et cetera), I then had a hybrid of
> storage and delivery.
>
> Mail the first digits to the sales email
> address(es) on file. Three addresses on two domains were used for
> redundancy in this case. Store the remaining digits in the database.
> You could write your own encryption algorithm or use one that is
> publicly-available and reversible (Blowfish is what I was using, at
> 128, key length of 56 lower ASCII characters, padded with 7 on the key
> and four on the output - MD5, SHA1, et al are NOT options here).
>
> The sales department then received the first digits of the credit
> card number via email, which stated it was an order key. Again, in my

Using the order number as the key is bad practice. Here is a random key
generator that you could use for your public/private keys and still use
the blowfish cipher as your method of encrypting:

function ReadFolder( $folder )
{
if( ( empty( $folder ) ) || ( !is_dir( $folder ) ) ) {
$rand_image = GenerateError( "Couldn't open directory" );
} else {
$rand_image = array();
if( $handle = opendir( $folder ) ) {
while( false !== ( $file = readdir( $handle ) ) ) {
if( $file != "." && $file != ".." && $file != "index.html" &&
!is_dir( $file ) ) {
$rand_image[] = $file;
}
}
closedir( $handle );
}
}
return $rand_image;
}

function MakeSuperRandom()
{
return srand( ( double ) microtime( time() ) * 100000 );
}

function PickRandomImages( $array )
{
$num1 = count( $array );
$num1 = $num1 - 1;
MakeSuperRandom();

$img_num = rand( 3, $num1 );
$image[] = $array[$img_num];

$num2 = count( $array );
$num2 = $num2 - 1;
MakeSuperRandom();

$img_num = rand( 3, $num2 );
$image[] = $array[$img_num];

$num3 = count( $array );
$num3 = $num3 - 1;
MakeSuperRandom();

$img_num = rand( 3, $num3 );
$image[] = $array[$img_num];
return $image;
}

function ChkArray( $array )
{
if( ( empty( $array ) ) || ( count( $array ) > 3 ) ) {
$data = 1;
} else {
$data = 0;
}
return $data;
}

function GeneratePrivKey( $array )
{
if( empty( $array ) ) {
$data = GenerateError( "Missing data for GeneratePrivKey function." );
} else {
for( $x = 0; $x < count( $array ); $x++ ) {
$keys[] = mhash( MHASH_SHA1, sha1( $array[$x] ) );
}
for( $y = 0; $y < count( $keys ); $y++ ) {
if( count( $keys ) == $keys[$y] ) {
$data .= $keys[$y];
} else {
$data .= $keys[$y] . ":";
}
}
}
return $data;
}

function GeneratePubKey( $data )
{
return md5( $data );
}

function EncData( $data, $key )
{
$td = mcrypt_module_open( 'rijndael-256', '', 'ofb', '' );
$iv = mcrypt_create_iv( mcrypt_enc_get_iv_size( $td ), MCRYPT_DEV_RANDOM );
$ks = mcrypt_enc_get_key_size( $td );
@mcrypt_generic_init( $td, $key, $iv );
$encrypted = mcrypt_generic( $td, $data );
echo "
Ciphered Text using Random Image Hash as Key:

 " .

$encrypted . "

"

.. $decrypted . "

" . $b . "

"; print_r( $data ); echo "

Re: Credit Card Encryption

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Gerfen wrote:
> Daniel Brown wrote:
>> On Dec 19, 2007 2:41 AM, Keith Spiller wrote:
>>> Ok I've done some research and some thinking. What about storing orders in
>>> the database (product info and customer info) and then using GnuPG or PGP to
>>> send the credit card info to the merchant? This way the credit card
>>> information is not stored on the server or in the database but only in
>>> printed format by the merchant. Since my client processes all of the credit
>>> card orders by hand this seems like an ideal solution.
>> I had a client that did offline (manual) processing of credit card
>> orders as well. With liability issues and the problems that others
>> have already pointed out, storing the credit card information was not
>> an option, yet my client still needed some way of having the data
>> available offline.
>
>> Consider the following:
>
>> ISSUER LENGTH
>> Diner's Club/Carte Blanche 14
>> American Express 15
>> VISA 13 or 16
>> MasterCard 16
>> Discover 16
>
>> Security checks aside (like making sure they selected the type of
>> card and that it matched the algorithm - VISA beginning with 4 and
>> being strlen($_POST['cardnum']) == 13 or 16, MasterCard being 16,
>> beginning with 51xx to 55xx, et cetera), I then had a hybrid of
>> storage and delivery.
>
>> Mail the first digits to the sales email
>> address(es) on file. Three addresses on two domains were used for
>> redundancy in this case. Store the remaining digits in the database.
>> You could write your own encryption algorithm or use one that is
>> publicly-available and reversible (Blowfish is what I was using, at
>> 128, key length of 56 lower ASCII characters, padded with 7 on the key
>> and four on the output - MD5, SHA1, et al are NOT options here).
>
>> The sales department then received the first digits of the credit
>> card number via email, which stated it was an order key. Again, in my
>
> Using the order number as the key is bad practice. Here is a random key
> generator that you could use for your public/private keys and still use
> the blowfish cipher as your method of encrypting:
>
> > function ReadFolder( $folder )
> {
> if( ( empty( $folder ) ) || ( !is_dir( $folder ) ) ) {
> $rand_image = GenerateError( "Couldn't open directory" );
> } else {
> $rand_image = array();
> if( $handle = opendir( $folder ) ) {
> while( false !== ( $file = readdir( $handle ) ) ) {
> if( $file != "." && $file != ".." && $file != "index.html" &&
> !is_dir( $file ) ) {
> $rand_image[] = $file;
> }
> }
> closedir( $handle );
> }
> }
> return $rand_image;
> }
>
> function MakeSuperRandom()
> {
> return srand( ( double ) microtime( time() ) * 100000 );
> }
>
> function PickRandomImages( $array )
> {
> $num1 = count( $array );
> $num1 = $num1 - 1;
> MakeSuperRandom();
>
> $img_num = rand( 3, $num1 );
> $image[] = $array[$img_num];
>
> $num2 = count( $array );
> $num2 = $num2 - 1;
> MakeSuperRandom();
>
> $img_num = rand( 3, $num2 );
> $image[] = $array[$img_num];
>
> $num3 = count( $array );
> $num3 = $num3 - 1;
> MakeSuperRandom();
>
> $img_num = rand( 3, $num3 );
> $image[] = $array[$img_num];
> return $image;
> }
>
> function ChkArray( $array )
> {
> if( ( empty( $array ) ) || ( count( $array ) > 3 ) ) {
> $data = 1;
> } else {
> $data = 0;
> }
> return $data;
> }
>
> function GeneratePrivKey( $array )
> {
> if( empty( $array ) ) {
> $data = GenerateError( "Missing data for GeneratePrivKey function." );
> } else {
> for( $x = 0; $x < count( $array ); $x++ ) {
> $keys[] = mhash( MHASH_SHA1, sha1( $array[$x] ) );
> }
> for( $y = 0; $y < count( $keys ); $y++ ) {
> if( count( $keys ) == $keys[$y] ) {
> $data .= $keys[$y];
> } else {
> $data .= $keys[$y] . ":";
> }
> }
> }
> return $data;
> }
>
> function GeneratePubKey( $data )
> {
> return md5( $data );
> }
>
> function EncData( $data, $key )
> {
> $td = mcrypt_module_open( 'rijndael-256', '', 'ofb', '' );
> $iv = mcrypt_create_iv( mcrypt_enc_get_iv_size( $td ), MCRYPT_DEV_RANDOM );
> $ks = mcrypt_enc_get_key_size( $td );
> @mcrypt_generic_init( $td, $key, $iv );
> $encrypted = mcrypt_generic( $td, $data );
> echo "
Ciphered Text using Random Image Hash as Key:

 " .

> $encrypted . "

"

> . $decrypted . "

" . $b . "

"; print_r( $data ); echo "

RE: Credit Card Encryption

--_f91cd930-81fd-43e7-9a51-86fc0698bfff_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Nope, I still would not recommmend it. The only place the CC data should tr=
avel to is the payment gateway. Anything else is a security risk. Why does =
your client process by hand? They should be using a payment gateway.=20
=20
bastien> From: larentium@hosthive.com> To: bastien_k@hotmail.com; php-db@li=
sts.php.net> Subject: Re: [PHP-DB] Credit Card Encryption> Date: Wed, 19 De=
c 2007 00:41:36 -0700> > Ok I've done some research and some thinking. What=
about storing orders in > the database (product info and customer info) an=
d then using GnuPG or PGP to > send the credit card info to the merchant? T=
his way the credit card > information is not stored on the server or in the=
database but only in > printed format by the merchant. Since my client pro=
cesses all of the credit > card orders by hand this seems like an ideal sol=
ution.> > What is more, the order and customer info do not need to be prese=
nt in the > encrypted emails. That way the email does not contain a custome=
r name, but > only an order id (which could even be a unique and hidden val=
ue stored via > AES in the mysql db).> > What are your thoughts?> > Keith> =
> ----- Original Message ----- > From: "Bastien Koert" om>> To: "Keith Spiller" ; > =
Sent: Tuesday, December 18, 2007 9:41 PM> Subject: RE: [PHP-DB] Credit Card=
Encryption> > > > Think very carefully about what you want to do here. PCI=
(payment card > industry) has radically changed the rules about how CC dat=
a is stored in a > networked environment. If your data environment is share=
d (shared web > hosting), don't even think about it. There are a large numb=
er of rules that > you need to follow to make your data systems PCI complia=
nt [ > http://www.pcicomplianceguide.org/ ] and they are not easy to follow=
.. Things > like strong encryption, code audits by qualified third parties e=
tc.> > If you absolutely need to store the data (many of my large clients d=
o this):> 1. the database server should not be web facing, nor accessible i=
nternally > by the web servers> 2. the access (physical and electronic) sho=
uld be extremely limited> 3. the facility that holds the data should be har=
dened with limited > controlled access> 4. provide a cross reference number=
to the CC that other applications can > use to replace the CC number> > If=
you are storing transactional data, just store the confirmation number > t=
hat is returned by the payment gateway that you use. Let the payment > gate=
way assume the risks of handling the data, its what they get paid for. > If=
the data is for re-occurring payments, let the payment gateway handle it, =
> many support these kinds of payments.> > Bastien> > From: larentium@hosth=
ive.com> To: php-db@lists.php.net> CC: > > larentium@hosthive.com> Date: Tu=
e, 18 Dec 2007 18:20:08 -0700> Subject: > > [PHP-DB] Credit Card Encryption=
> > Hi Everyone,> > I'm trying to determine > > the best method to store cr=
edit card numbers in a > mysql database. As yet > > I have been unable to d=
etermine whether I should use > MySQL AES, DES or a > > PHP encryption meth=
od. I would greatly appreciate any > advice you guys > > could offer.> > Th=
anks.> > Keith > > -- > PHP Database Mailing List > > (http://www.php.net/)=
> To unsubscribe, visit: > > http://www.php.net/unsub.php>> _______________=
__________________________________________________> Discover new ways to st=
ay in touch with Windows Live! Visit the City @ Live > today!> http://getyo=
urliveid.ca/?icid=3DLIVEIDENCA006 >=20
____________________________________________________________ _____
Introducing the City @ Live! Take a tour!
http://getyourliveid.ca/?icid=3DLIVEIDENCA006=

--_f91cd930-81fd-43e7-9a51-86fc0698bfff_--

Re: Credit Card Encryption

On Dec 19, 2007 4:45 PM, Bastien Koert wrote:
>
> Nope, I still would not recommmend it. The only place the CC data should travel to is the payment gateway. Anything else is a security risk. Why does your client process by hand? They should be using a payment gateway.

That's true, Bastien, but if for whatever reason it's not an
option for them, what? Tell them it's tough cookies and they're SOL?

Our job as programmers - especially freelance - is to make things
happen as safely and securely as we can, but as a bottom line, make it
happen. I'm sure we (most of us) take the responsibility to
discourage a client from making such choices, and to educate them on
alternatives that are better for their interests, but still - at the
end of the day, we're still just code monkeys. We're expected to
build what the client needs, or else they'll find someone else to do
it for them.

And I don't really like to go hungry. ;-)

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Credit Card Encryption

--_ec2911c9-5086-49ca-9d57-1f4ac712a431_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Dan,
=20
Normally I would completely agree, its our job to find those solutions. Unf=
ortunately, the sector that my FT job deals with is retail and many of our =
clients are in this bind with PCI data. Hefty fines are charged to those no=
t in compliance. The major CC companies are taking this so seriously and th=
e ramifications are being felt in many IT shops. Compliance failure can lea=
d to loss o privileges to accept CCs.
=20
Its gonna force us to be more creative in how we handle the data and create=
the applications that allow our clients to offer ecommerce, we will have t=
o learn some business skills to make this happen. It may mean that its beco=
mes more contractual in dealing with third parties, where the ecommece shop=
effects payment on behalf of the vendors. The OP may need to help his clie=
nt work out a better way to manage the transactions between the related par=
ties by finding ways to automate the various transactions and provide gatew=
ay access...
=20
I, too, like to eat... ;-P
=20
bastien
=20
=20
> Date: Wed, 19 Dec 2007 17:21:57 -0500> From: parasane@gmail.com> To: bast=
ien_k@hotmail.com> Subject: Re: [PHP-DB] Credit Card Encryption> CC: larent=
ium@hosthive.com; php-db@lists.php.net> > On Dec 19, 2007 4:45 PM, Bastien =
Koert wrote:> >> > Nope, I still would not recommme=
nd it. The only place the CC data should travel to is the payment gateway. =
Anything else is a security risk. Why does your client process by hand? The=
y should be using a payment gateway.> > That's true, Bastien, but if for wh=
atever reason it's not an> option for them, what? Tell them it's tough cook=
ies and they're SOL?> > Our job as programmers - especially freelance - is =
to make things> happen as safely and securely as we can, but as a bottom li=
ne, make it> happen. I'm sure we (most of us) take the responsibility to> d=
iscourage a client from making such choices, and to educate them on> altern=
atives that are better for their interests, but still - at the> end of the =
day, we're still just code monkeys. We're expected to> build what the clien=
t needs, or else they'll find someone else to do> it for them.> > And I don=
't really like to go hungry. ;-)> > -- > Daniel P. Brown> [Phone Numbers Go=
Here!]> [They're Hidden From View!]> > If at first you don't succeed, stic=
k to what you know best so that you> can make enough money to pay someone e=
lse to do it for you.
____________________________________________________________ _____
Exercise your brain! Try Flexicon!
http://puzzles.sympatico.msn.ca/chicktionary/index.html?icid =3Dhtmlsig=

--_ec2911c9-5086-49ca-9d57-1f4ac712a431_--

RE: Credit Card Encryption

Hmm,

This is kind of throwing a new twist on things.

When it comes to liability, who is liable, the merchant running the system, the develper that created the system, or both?

If the develper is included, would that be mitigated in that he created the system to the merchant's specifications?

Also, in terms of the developer, would this be covered under errors and omissions insurance, or would they take the position that
the developer should have known better and was negligent in creating a non-compliant system leaving the developer on the hook for
damages?

Gary

> -----Original Message-----
> From: Bastien Koert [mailto:bastien_k@hotmail.com]
> Sent: Wed, December 19, 2007 11:02 PM
> To: Daniel Brown
> Cc: Keith Spiller; php-db@lists.php.net
> Subject: RE: [PHP-DB] Credit Card Encryption
>
>
>
> Dan,
>
> Normally I would completely agree, its our job to find those
> solutions. Unfortunately, the sector that my FT job deals
> with is retail and many of our clients are in this bind with
> PCI data. Hefty fines are charged to those not in compliance.
> The major CC companies are taking this so seriously and the
> ramifications are being felt in many IT shops. Compliance
> failure can lead to loss o privileges to accept CCs.
>
> Its gonna force us to be more creative in how we handle the
> data and create the applications that allow our clients to
> offer ecommerce, we will have to learn some business skills
> to make this happen. It may mean that its becomes more
> contractual in dealing with third parties, where the ecommece
> shop effects payment on behalf of the vendors. The OP may
> need to help his client work out a better way to manage the
> transactions between the related parties by finding ways to
> automate the various transactions and provide gateway access...
>
> I, too, like to eat... ;-P
>
> bastien
>
>
> > Date: Wed, 19 Dec 2007 17:21:57 -0500> From:
> parasane@gmail.com> To: bastien_k@hotmail.com> Subject: Re:
> [PHP-DB] Credit Card Encryption> CC: larentium@hosthive.com;
> php-db@lists.php.net> > On Dec 19, 2007 4:45 PM, Bastien
> Koert wrote:> >> > Nope, I still
> would not recommmend it. The only place the CC data should
> travel to is the payment gateway. Anything else is a security
> risk. Why does your client process by hand? They should be
> using a payment gateway.> > That's true, Bastien, but if for
> whatever reason it's not an> option for them, what? Tell them
> it's tough cookies and they're SOL?> > Our job as programmers
> - especially freelance - is to make things> happen as safely
> and securely as we can, but as a bottom line, make it>
> happen. I'm sure we (most of us) take the responsibility to>
> discourage a client from making such choices, and to educate
> them on> alternatives that are better for their interests,
> but still - at the> end of the day, we're still just code
> monkeys. We're expected to> build what the client needs, or
> else they'll find someone else to do> it for them.> > And I
> don't really like to go hungry. ;-)> > -- > Daniel P. Brown>
> [Phone Numbers Go Here!]> [They're Hidden From View!]> > If
> at first you don't succeed, stick to what you know best so
> that you> can make enough money to pay someone else to do it for you.
> ____________________________________________________________ _____
> Exercise your brain! Try Flexicon!
> http://puzzles.sympatico.msn.ca/chicktionary/index.html?icid =htmlsig

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Credit Card Encryption

--_8882d93c-696e-4591-aeb1-f68dcecd9336_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Gary,
=20
I take the view that I warn our customers about the dangers, and if really =
concerning ask for an indemnity or a very formal request for change. I real=
ly try to convince them of the correct path and keep any emails regarding t=
he issues as backup
=20
Its a drag when you really have to consider how to cover your ass on this. =
Lawyers suck too. ;-P
=20
bastien> From: gwardell@gwsystems.co.il> To: bastien_k@hotmail.com> CC: php=
-db@lists.php.net> Subject: RE: [PHP-DB] Credit Card Encryption> Date: Wed,=
19 Dec 2007 23:21:52 -0500> > Hmm,> > This is kind of throwing a new twist=
on things.> > When it comes to liability, who is liable, the merchant runn=
ing the system, the develper that created the system, or both?> > If the de=
velper is included, would that be mitigated in that he created the system t=
o the merchant's specifications?> > Also, in terms of the developer, would =
this be covered under errors and omissions insurance, or would they take th=
e position that> the developer should have known better and was negligent i=
n creating a non-compliant system leaving the developer on the hook for> da=
mages?> > Gary> > > -----Original Message-----> > From: Bastien Koert [mail=
to:bastien_k@hotmail.com]> > Sent: Wed, December 19, 2007 11:02 PM> > To: D=
aniel Brown> > Cc: Keith Spiller; php-db@lists.php.net> > Subject: RE: [PHP=
-DB] Credit Card Encryption> >> >> >> > Dan,> >> > Normally I would complet=
ely agree, its our job to find those> > solutions. Unfortunately, the secto=
r that my FT job deals> > with is retail and many of our clients are in thi=
s bind with> > PCI data. Hefty fines are charged to those not in compliance=
..> > The major CC companies are taking this so seriously and the> > ramific=
ations are being felt in many IT shops. Compliance> > failure can lead to l=
oss o privileges to accept CCs.> >> > Its gonna force us to be more creativ=
e in how we handle the> > data and create the applications that allow our c=
lients to> > offer ecommerce, we will have to learn some business skills> >=
to make this happen. It may mean that its becomes more> > contractual in d=
ealing with third parties, where the ecommece> > shop effects payment on be=
half of the vendors. The OP may> > need to help his client work out a bette=
r way to manage the> > transactions between the related parties by finding =
ways to> > automate the various transactions and provide gateway access...>=
>> > I, too, like to eat... ;-P> >> > bastien> >> >> > > Date: Wed, 19 Dec=
2007 17:21:57 -0500> From:> > parasane@gmail.com> To: bastien_k@hotmail.co=
m> Subject: Re:> > [PHP-DB] Credit Card Encryption> CC: larentium@hosthive.=
com;> > php-db@lists.php.net> > On Dec 19, 2007 4:45 PM, Bastien> > Koert <=
bastien_k@hotmail.com> wrote:> >> > Nope, I still> > would not recommmend i=
t. The only place the CC data should> > travel to is the payment gateway. A=
nything else is a security> > risk. Why does your client process by hand? T=
hey should be> > using a payment gateway.> > That's true, Bastien, but if f=
or> > whatever reason it's not an> option for them, what? Tell them> > it's=
tough cookies and they're SOL?> > Our job as programmers> > - especially f=
reelance - is to make things> happen as safely> > and securely as we can, b=
ut as a bottom line, make it>> > happen. I'm sure we (most of us) take the =
responsibility to>> > discourage a client from making such choices, and to =
educate> > them on> alternatives that are better for their interests,> > bu=
t still - at the> end of the day, we're still just code> > monkeys. We're e=
xpected to> build what the client needs, or> > else they'll find someone el=
se to do> it for them.> > And I> > don't really like to go hungry. ;-)> > -=
- > Daniel P. Brown>> > [Phone Numbers Go Here!]> [They're Hidden From View=
!]> > If> > at first you don't succeed, stick to what you know best so> > t=
hat you> can make enough money to pay someone else to do it for you.> > ___=
____________________________________________________________ __> > Exercise =
your brain! Try Flexicon!> > http://puzzles.sympatico.msn.ca/chicktionary/i=
ndex.html?icid=3Dhtmlsig>=20
____________________________________________________________ _____
Exercise your brain! Try Flexicon!
http://puzzles.sympatico.msn.ca/chicktionary/index.html?icid =3Dhtmlsig=

--_8882d93c-696e-4591-aeb1-f68dcecd9336_--

Re: Credit Card Encryption

On Dec 19, 2007 11:59 PM, Bastien Koert wrote:
> I take the view that I warn our customers about the dangers, and if really concerning ask for an indemnity or a very formal request for change. I really try to convince them of the correct path and keep any emails regarding the issues as backup

I was going to say the same thing. If PCI is really becoming that
big of an issue where there's even the slightest threat of backlash to
the developer, an indemnification clause (Santa's European cousin)
should probably be the course of action. That said, I think I'm going
to peruse the compliance information at that link you sent earlier.

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Credit Card Encryption

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I got messaged off list which I don't appreciate.

But, yes PHP5 only or you could replace the lines for PHP4 and on:

$keys[] = mhash( MHASH_SHA1, sha1( $array[$x] ) );

With:

if( !function_exists( mhash ) ) {
$keys[] = sha1( sha1( $array[$x] ) );
} elseif( !function_exists( sha1 ) ) {
$keys[] = md5( md5( $array[$x] ) );
} else {
$keys[] = mhash( MHASH_SHA1, sha1( $array[$x] ) );
}

That will look to see if the 'mhash()', 'sha1()' functions exist and use
them accordingly. HTH.

Jason Gerfen wrote:
> Jason Gerfen wrote:
>> Daniel Brown wrote:
>>> On Dec 19, 2007 2:41 AM, Keith Spiller wrote:
>>>> Ok I've done some research and some thinking. What about storing orders in
>>>> the database (product info and customer info) and then using GnuPG or PGP to
>>>> send the credit card info to the merchant? This way the credit card
>>>> information is not stored on the server or in the database but only in
>>>> printed format by the merchant. Since my client processes all of the credit
>>>> card orders by hand this seems like an ideal solution.
>>> I had a client that did offline (manual) processing of credit card
>>> orders as well. With liability issues and the problems that others
>>> have already pointed out, storing the credit card information was not
>>> an option, yet my client still needed some way of having the data
>>> available offline.
>>> Consider the following:
>>> ISSUER LENGTH
>>> Diner's Club/Carte Blanche 14
>>> American Express 15
>>> VISA 13 or 16
>>> MasterCard 16
>>> Discover 16
>>> Security checks aside (like making sure they selected the type of
>>> card and that it matched the algorithm - VISA beginning with 4 and
>>> being strlen($_POST['cardnum']) == 13 or 16, MasterCard being 16,
>>> beginning with 51xx to 55xx, et cetera), I then had a hybrid of
>>> storage and delivery.
>>> Mail the first digits to the sales email
>>> address(es) on file. Three addresses on two domains were used for
>>> redundancy in this case. Store the remaining digits in the database.
>>> You could write your own encryption algorithm or use one that is
>>> publicly-available and reversible (Blowfish is what I was using, at
>>> 128, key length of 56 lower ASCII characters, padded with 7 on the key
>>> and four on the output - MD5, SHA1, et al are NOT options here).
>>> The sales department then received the first digits of the credit
>>> card number via email, which stated it was an order key. Again, in my
>> Using the order number as the key is bad practice. Here is a random key
>> generator that you could use for your public/private keys and still use
>> the blowfish cipher as your method of encrypting:
>
>> >> function ReadFolder( $folder )
>> {
>> if( ( empty( $folder ) ) || ( !is_dir( $folder ) ) ) {
>> $rand_image = GenerateError( "Couldn't open directory" );
>> } else {
>> $rand_image = array();
>> if( $handle = opendir( $folder ) ) {
>> while( false !== ( $file = readdir( $handle ) ) ) {
>> if( $file != "." && $file != ".." && $file != "index.html" &&
>> !is_dir( $file ) ) {
>> $rand_image[] = $file;
>> }
>> }
>> closedir( $handle );
>> }
>> }
>> return $rand_image;
>> }
>
>> function MakeSuperRandom()
>> {
>> return srand( ( double ) microtime( time() ) * 100000 );
>> }
>
>> function PickRandomImages( $array )
>> {
>> $num1 = count( $array );
>> $num1 = $num1 - 1;
>> MakeSuperRandom();
>
>> $img_num = rand( 3, $num1 );
>> $image[] = $array[$img_num];
>
>> $num2 = count( $array );
>> $num2 = $num2 - 1;
>> MakeSuperRandom();
>
>> $img_num = rand( 3, $num2 );
>> $image[] = $array[$img_num];
>
>> $num3 = count( $array );
>> $num3 = $num3 - 1;
>> MakeSuperRandom();
>
>> $img_num = rand( 3, $num3 );
>> $image[] = $array[$img_num];
>> return $image;
>> }
>
>> function ChkArray( $array )
>> {
>> if( ( empty( $array ) ) || ( count( $array ) > 3 ) ) {
>> $data = 1;
>> } else {
>> $data = 0;
>> }
>> return $data;
>> }
>
>> function GeneratePrivKey( $array )
>> {
>> if( empty( $array ) ) {
>> $data = GenerateError( "Missing data for GeneratePrivKey function." );
>> } else {
>> for( $x = 0; $x < count( $array ); $x++ ) {
>> $keys[] = mhash( MHASH_SHA1, sha1( $array[$x] ) );
>> }
>> for( $y = 0; $y < count( $keys ); $y++ ) {
>> if( count( $keys ) == $keys[$y] ) {
>> $data .= $keys[$y];
>> } else {
>> $data .= $keys[$y] . ":";
>> }
>> }
>> }
>> return $data;
>> }
>
>> function GeneratePubKey( $data )
>> {
>> return md5( $data );
>> }
>
>> function EncData( $data, $key )
>> {
>> $td = mcrypt_module_open( 'rijndael-256', '', 'ofb', '' );
>> $iv = mcrypt_create_iv( mcrypt_enc_get_iv_size( $td ), MCRYPT_DEV_RANDOM );
>> $ks = mcrypt_enc_get_key_size( $td );
>> @mcrypt_generic_init( $td, $key, $iv );
>> $encrypted = mcrypt_generic( $td, $data );
>> echo "
Ciphered Text using Random Image Hash as Key:

 " .

>> $encrypted . "

"

>> . $decrypted . "

" . $b . "

"; print_r( $data ); echo "

Re: Credit Card Encryption

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What I wrote there will work but I would highly recommend recompiling
PHP with the --with-mcrypt --with-mhash switches. The mcrypt libraries
can be found on sourceforge. http://libmcrypt.sourceforge.net

Jason Gerfen wrote:
> I got messaged off list which I don't appreciate.
>
> But, yes PHP5 only or you could replace the lines for PHP4 and on:
>
> $keys[] = mhash( MHASH_SHA1, sha1( $array[$x] ) );
>
> With:
>
> if( !function_exists( mhash ) ) {
> $keys[] = sha1( sha1( $array[$x] ) );
> } elseif( !function_exists( sha1 ) ) {
> $keys[] = md5( md5( $array[$x] ) );
> } else {
> $keys[] = mhash( MHASH_SHA1, sha1( $array[$x] ) );
> }
>
> That will look to see if the 'mhash()', 'sha1()' functions exist and use
> them accordingly. HTH.
>
> Jason Gerfen wrote:
>> Jason Gerfen wrote:
>>> Daniel Brown wrote:
>>>> On Dec 19, 2007 2:41 AM, Keith Spiller wrote:
>>>>> Ok I've done some research and some thinking. What about storing orders in
>>>>> the database (product info and customer info) and then using GnuPG or PGP to
>>>>> send the credit card info to the merchant? This way the credit card
>>>>> information is not stored on the server or in the database but only in
>>>>> printed format by the merchant. Since my client processes all of the credit
>>>>> card orders by hand this seems like an ideal solution.
>>>> I had a client that did offline (manual) processing of credit card
>>>> orders as well. With liability issues and the problems that others
>>>> have already pointed out, storing the credit card information was not
>>>> an option, yet my client still needed some way of having the data
>>>> available offline.
>>>> Consider the following:
>>>> ISSUER LENGTH
>>>> Diner's Club/Carte Blanche 14
>>>> American Express 15
>>>> VISA 13 or 16
>>>> MasterCard 16
>>>> Discover 16
>>>> Security checks aside (like making sure they selected the type of
>>>> card and that it matched the algorithm - VISA beginning with 4 and
>>>> being strlen($_POST['cardnum']) == 13 or 16, MasterCard being 16,
>>>> beginning with 51xx to 55xx, et cetera), I then had a hybrid of
>>>> storage and delivery.
>>>> Mail the first digits to the sales email
>>>> address(es) on file. Three addresses on two domains were used for
>>>> redundancy in this case. Store the remaining digits in the database.
>>>> You could write your own encryption algorithm or use one that is
>>>> publicly-available and reversible (Blowfish is what I was using, at
>>>> 128, key length of 56 lower ASCII characters, padded with 7 on the key
>>>> and four on the output - MD5, SHA1, et al are NOT options here).
>>>> The sales department then received the first digits of the credit
>>>> card number via email, which stated it was an order key. Again, in my
>>> Using the order number as the key is bad practice. Here is a random key
>>> generator that you could use for your public/private keys and still use
>>> the blowfish cipher as your method of encrypting:
>>> >>> function ReadFolder( $folder )
>>> {
>>> if( ( empty( $folder ) ) || ( !is_dir( $folder ) ) ) {
>>> $rand_image = GenerateError( "Couldn't open directory" );
>>> } else {
>>> $rand_image = array();
>>> if( $handle = opendir( $folder ) ) {
>>> while( false !== ( $file = readdir( $handle ) ) ) {
>>> if( $file != "." && $file != ".." && $file != "index.html" &&
>>> !is_dir( $file ) ) {
>>> $rand_image[] = $file;
>>> }
>>> }
>>> closedir( $handle );
>>> }
>>> }
>>> return $rand_image;
>>> }
>>> function MakeSuperRandom()
>>> {
>>> return srand( ( double ) microtime( time() ) * 100000 );
>>> }
>>> function PickRandomImages( $array )
>>> {
>>> $num1 = count( $array );
>>> $num1 = $num1 - 1;
>>> MakeSuperRandom();
>>> $img_num = rand( 3, $num1 );
>>> $image[] = $array[$img_num];
>>> $num2 = count( $array );
>>> $num2 = $num2 - 1;
>>> MakeSuperRandom();
>>> $img_num = rand( 3, $num2 );
>>> $image[] = $array[$img_num];
>>> $num3 = count( $array );
>>> $num3 = $num3 - 1;
>>> MakeSuperRandom();
>>> $img_num = rand( 3, $num3 );
>>> $image[] = $array[$img_num];
>>> return $image;
>>> }
>>> function ChkArray( $array )
>>> {
>>> if( ( empty( $array ) ) || ( count( $array ) > 3 ) ) {
>>> $data = 1;
>>> } else {
>>> $data = 0;
>>> }
>>> return $data;
>>> }
>>> function GeneratePrivKey( $array )
>>> {
>>> if( empty( $array ) ) {
>>> $data = GenerateError( "Missing data for GeneratePrivKey function." );
>>> } else {
>>> for( $x = 0; $x < count( $array ); $x++ ) {
>>> $keys[] = mhash( MHASH_SHA1, sha1( $array[$x] ) );
>>> }
>>> for( $y = 0; $y < count( $keys ); $y++ ) {
>>> if( count( $keys ) == $keys[$y] ) {
>>> $data .= $keys[$y];
>>> } else {
>>> $data .= $keys[$y] . ":";
>>> }
>>> }
>>> }
>>> return $data;
>>> }
>>> function GeneratePubKey( $data )
>>> {
>>> return md5( $data );
>>> }
>>> function EncData( $data, $key )
>>> {
>>> $td = mcrypt_module_open( 'rijndael-256', '', 'ofb', '' );
>>> $iv = mcrypt_create_iv( mcrypt_enc_get_iv_size( $td ), MCRYPT_DEV_RANDOM );
>>> $ks = mcrypt_enc_get_key_size( $td );
>>> @mcrypt_generic_init( $td, $key, $iv );
>>> $encrypted = mcrypt_generic( $td, $data );
>>> echo "
Ciphered Text using Random Image Hash as Key:

 " .

>>> $encrypted . "

"

>>> . $decrypted . "

" . $b . "

"; print_r( $data ); echo "