RE: Credit Card Encryption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. 
 
bastien> From: larentium@xxxxxxxxxxxx> To: bastien_k@xxxxxxxxxxx; php-db@xxxxxxxxxxxxx> Subject: Re:  Credit Card Encryption> Date: Wed, 19 Dec 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) 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" <bastien_k@xxxxxxxxxxx>> To: "Keith Spiller" <larentium@xxxxxxxxxxxx>; <php-db@xxxxxxxxxxxxx>> Sent: Tuesday, December 18, 2007 9:41 PM> Subject: RE:  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@xxxxxxxxxxxx> To: php-db@xxxxxxxxxxxxx> CC: > > larentium@xxxxxxxxxxxx> Date: Tue, 18 Dec 2007 18:20:08 -0700> Subject: > >  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 > 
_________________________________________________________________
Introducing the City @ Live! Take a tour!
http://getyourliveid.ca/?icid=LIVEIDENCA006

[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux