On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: > At 12:43 PM +0200 5/30/10, Peter Lind wrote: >>> On 30 May 2010 07:49, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: >>> -snip- >>> >>> Does anyone have a better solution? >> >> I'm sorry if the following sounds a bit harsh, but in matters like >> these I prefer blunt directness. >> >> A few notes. 1) one-way encryption means "no decrypting" - that's what >> one-way is (like a one-way street, there's no driving the other >> direction). You're looking for encryption that can be decrypted, not >> one-way encryption which is otherwise known as hashing. 2) do not >> store credit card information. Just don't. It's downright stupid to do >> so, because it's a huge risk for very little gain. 3) farm out risks >> like these to companies that specialize in dealing with them - you >> will with 100% certainty not be able to do as good a job as these. >> >> The question to ask is not: how to store credit card information >> securely? The question to ask is: do I really want to be the next >> person in the internet spotlight because my setup turned out to have a >> security hole I overlooked? > > Paul: > > Let me be equally blunt. Petter is absolutely right! > > Do NOT have your client store customer credit card information on a > server -- period! That's the stuff people go to jail over. Instead, > use a credit card clearing house to do the heavy work, that's what > they get paid for. > > Besides, most credit card processing agencies even require that you > use the customer's data (cc number, expiry date and CCS) to make the > sale and then immediately dispose of it afterwards, usually within 24 > hours under a signed agreement. Holding that information for more > than 24 hours can be a criminal offense regardless of what type of > hashing you use. Not true. It depends on the type of merchant and the situation. The PCI validation process allows for storage of all data except the 3-4 digit validation number. What I'm asked for at transaction time is the CC number, expiration date, digits for the billing address, and the billing zip code. And I can get the address and zip digits completely wrong and still have the transaction go through. > > While many of my customers have made the argument that they keep > hard-copy records of their customer's credit-card information > in-house and they don't understand why they can't do the same online > -- I reply that hard-copy kept in a safe behind "brick and mortar" in > far more secure that digital data behind any "security" code open to > the world. There isn't a security system out there that can't be > hacked. If the client insists on keeping this information online, > then find another client because at some time, someone is going to > jail and it's not going to be me. Of course, any system can be hacked. PCI guidelines are designed to ensure that measures are in place to minimize that non-zero risk. > > So, let the people who can keep up with technology (a continued > effort and expense) worry about hackers -- just use their services > and sleep at night. > We've been doing it this way for 14 years and using the type of service you suggest would be expensive and impractical. Only in the last two years has PCI become more stringent in their requirements. And consequently, I'm having to re-evaluate how we store this particular information. Otherwise, our physical and other security is more than adequate. Yes, of course, if you have a machine gun or you're Kevin Mitnick, or you have a network of 20,000 bots pounding on my router, you're coming in anyway. Again, this is about *reasonable* security. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
