Credit Card encryption
in [General]
|
From: Miles Thompson on 30 May 2010 15:17 On Sun, May 30, 2010 at 11:50 AM, tedd <tedd.sperling(a)gmail.com> wrote: > At 12:43 PM +0200 5/30/10, Peter Lind wrote: > >> On 30 May 2010 07:49, Paul M Foster <paulf(a)quillandmouse.com> 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. > > 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. > > 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. > > > Cheers, > > tedd > > > To add my two cents - if you plan to store card information, in the eyes of the Payment Card Industry you will have to be Tier One compliant. How high are the standards? Visit hackerguardian.com and take the free test. We *thought* it might be cool to store the CC info for a new enterprise, provide convenient "one-click" shopping, etc, so we ran through the questionnaire at that level. It would take more time to design, implement and test the security and audit systems than to write the app. Furthermore, since we were doing the new project in the cloud we could not meet the requirements for physical security. So we settled for Tier4 - we take the information as part of the transaction, https to CC processor, get an "OK" or "Not OK" back, and no cardholder info stored on our server at all, apart from the transaction number. Cheers - Miles Thompson ~~~~~~~~~~~~~~~~~~~~~~~~~~ "The piano keys are black and white, But they sound like a million colours in your mind" Spider's Web - Katie Melua
From: Phpster on 30 May 2010 15:30 On May 30, 2010, at 10:50 AM, tedd <tedd.sperling(a)gmail.com> wrote: > At 12:43 PM +0200 5/30/10, Peter Lind wrote: >>> On 30 May 2010 07:49, Paul M Foster <paulf(a)quillandmouse.com> 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. > > 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. > > 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. > > Cheers, > > tedd > > -- > ------- > http://sperling.com http://ancientstones.com http://earthstones.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > I work with some of the largest retailers in north America if not the world, and I can confirm that the security measures taken to enforce pci compliance are not something lightly undertaken. If those entities choose to store the cc#s then they do the following: 1. Store the encrypted values on servers that are NOT web facing 2. Use ridiculously long encryption keys ( well into the 1000s of characters) 3. They also create a representative value that exists outside the system that has to allow some basis of data mining. Really as mentioned you don't want to do this. Especially if you have no control over the servers. Bastien Sent from my iPod
From: Paul M Foster on 31 May 2010 01:13 On Sun, May 30, 2010 at 03:12:10AM -0400, Adam Richardson wrote: > On Sun, May 30, 2010 at 2:16 AM, Ashley Sheridan > <ash(a)ashleysheridan.co.uk>wrote: > > > On Sun, 2010-05-30 at 01:49 -0400, Paul M Foster wrote: > > <snip> > > Hi Paul, > > When you describe one-way or two-way encryption, what are you describing? > Are you describing hashing vs encryption where the plain-text is > recoverable with a key, or are you describing symmetric (one key handles > encrypting and decrypting) vs asymmetric (separate keys handle encrypting > and decrypting) encryption? I'm not very good with this terminology. What I mean is that there's no way to decrypt the value without the key, and the key is not stored on the system. This would be like password storage on *nix systems-- if you forget the password, there's no practical way to log in. (Yes, I know there are dictionary-based and brute force methods, but in general, if you forget your password, you're screwed.) What PCI wants is strong encryption. I take this to mean that keys are long enough to be practically invulnerable to hacking. > > Now if you one-way encrypt the credit card numbers in the customer > > records, then it seems to me that any time that field has to be accessed > > (to edit the record or charge something to the card), you'd have to have > > the user enter a specific "password" to unlock the encryption. > > > You can't decrypt (or "unlock") a hashed password (at least if you used a > secure hash), but I'm not sure you're talking about symmetric vs asymmetric > encryption, either. With more details , I can provide feedback on the > encryption schemes you're considering (remember, you have to make sure that > you are managing encryption keys very carefully, as among other things, PCI > requires that "keys are stored in encrypted format and that key- encrypting > keys are stored separately from data- encrypting keys.") By "assymetric", I take it you mean like PGP or GPG, where there are public and private keys? I don't really understand this technology, and I'm not sure it matters. <snip> Paul -- Paul M. Foster
From: Paul M Foster on 31 May 2010 01:24 On Sun, May 30, 2010 at 03:30:28PM -0400, Phpster wrote: <snip> > > I work with some of the largest retailers in north America if not the > world, and I can confirm that the security measures taken to enforce > pci compliance are not something lightly undertaken. > > If those entities choose to store the cc#s then they do the following: > > 1. Store the encrypted values on servers that are NOT web facing Absolutely! If I were trying to do this on a web server, I *would* use a payment gateway. There's no way I could secure it adequately otherwise. > > 2. Use ridiculously long encryption keys ( well into the 1000s of > characters) > > 3. They also create a representative value that exists outside the > system that has to allow some basis of data mining. > > > Really as mentioned you don't want to do this. Especially if you have > no control over the servers. I have complete control over the server this information is stored on, including physical control. It is behind a NATed firewall and only accessible to certain machines on my internal network. The only personnel with access to the server are myself and my wife. To be clear, we process credit cards MOTO, meaning we have no physical access to the cards themselves. We use a small terminal which dials up our payment processor to get approvals. The problem is that virtually all of our credit card business is with the same customers and recurring. So it's not feasible to call them every month or several times per job to ask for a credit card number. This would aggravate my customers. So I have to store the information one way or another, on 3x5 cards, in the computer or some way. And it appears from all the replies that there is no other way to do it than to have a separate key or password for accessing just these credit card numbers, and every time they must be accessed, the user must provide this key, which would be in addition to the usual password for that user. Paul -- Paul M. Foster
From: Paul M Foster on 31 May 2010 01:38
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(a)quillandmouse.com> 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 |