Credit Card encryption
in [General]
|
From: Paul M Foster on 30 May 2010 01:49 This question is for people who take and store credit card information for customers. Credit card companies, in an attempt to lessen fraud, are tightening the screws on merchants who take credit cards. One aspect of this is a requirement to store credit card information from customers encrypted. So let's say you have a customer whose credit card you keep on file, because they'll be charging other items with you. The credit card companies would like you to store this information with strong encryption, which in their mind is one-way encryption. Now let's say that the credit card number is part of the customer record. When looking at the customer record, you see just the last four digits of the card. But when editing the record or when printing out reports of things which must be charged, you will see the whole number. Assume the users of the system have logins and passwords. 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. This would be quite in addition to their username and password. Moreover for this to be as secure as the credit card companies would like it, whatever "password" is used would need to be changed frequently, particularly at any change of personnel. This means you'd have to re-encrypt all the credit card numbers using the new "password" every few months or when you fire someone who had access to the data. This seems like an excessively cumbersome solution. Is this seriously the way it's done? Does anyone have a better solution? Paul -- Paul M. Foster
From: Ashley Sheridan on 30 May 2010 02:16 On Sun, 2010-05-30 at 01:49 -0400, Paul M Foster wrote: > This question is for people who take and store credit card information > for customers. > > Credit card companies, in an attempt to lessen fraud, are tightening the > screws on merchants who take credit cards. One aspect of this is a > requirement to store credit card information from customers encrypted. > > So let's say you have a customer whose credit card you keep on file, > because they'll be charging other items with you. The credit card > companies would like you to store this information with strong > encryption, which in their mind is one-way encryption. > > Now let's say that the credit card number is part of the customer > record. When looking at the customer record, you see just the last four > digits of the card. But when editing the record or when printing out > reports of things which must be charged, you will see the whole number. > Assume the users of the system have logins and passwords. > > 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. This > would be quite in addition to their username and password. Moreover for > this to be as secure as the credit card companies would like it, > whatever "password" is used would need to be changed frequently, > particularly at any change of personnel. This means you'd have to > re-encrypt all the credit card numbers using the new "password" every > few months or when you fire someone who had access to the data. > > This seems like an excessively cumbersome solution. Is this seriously > the way it's done? Does anyone have a better solution? > > > Paul > > -- > Paul M. Foster > It's not just a matter of encrypting the credit card details. You also have to ensure the server meets specific security requirements, every last little bit of software has to be updated and patched. There are services that will check your server out for you (last one I used was McAffee Secure) I am certain that this is a legal requirement in order to allow you to process credit card details. You won't have to encrypt the password against the username of whoever has access to it. Just encrypt it the once, and use the DBMS side of things to manage access rights. Maybe use a couple of fields in the DB to store the credit card number in two versions, one that is two-way encrypted, the second that is one-way. You can set up your web system to only have access to the one-way version, meaning that the actual number can't be got by that user. The two-way encrypted version would be accessible only by a specific second DB user, the access details of which could change when personnel changes. Thanks, Ash http://www.ashleysheridan.co.uk
From: Adam Richardson on 30 May 2010 03:12 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: > > > This question is for people who take and store credit card information > > for customers. > > > > Credit card companies, in an attempt to lessen fraud, are tightening the > > screws on merchants who take credit cards. One aspect of this is a > > requirement to store credit card information from customers encrypted. > > > > So let's say you have a customer whose credit card you keep on file, > > because they'll be charging other items with you. The credit card > > companies would like you to store this information with strong > > encryption, which in their mind is one-way encryption. > > > > Now let's say that the credit card number is part of the customer > > record. When looking at the customer record, you see just the last four > > digits of the card. But when editing the record or when printing out > > reports of things which must be charged, you will see the whole number. > > Assume the users of the system have logins and passwords. > > > > 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. This > > would be quite in addition to their username and password. Moreover for > > this to be as secure as the credit card companies would like it, > > whatever "password" is used would need to be changed frequently, > > particularly at any change of personnel. This means you'd have to > > re-encrypt all the credit card numbers using the new "password" every > > few months or when you fire someone who had access to the data. > > > > This seems like an excessively cumbersome solution. Is this seriously > > the way it's done? Does anyone have a better solution? > > > > > > Paul > > > > -- > > Paul M. Foster > > > > > It's not just a matter of encrypting the credit card details. You also > have to ensure the server meets specific security requirements, every > last little bit of software has to be updated and patched. There are > services that will check your server out for you (last one I used was > McAffee Secure) I am certain that this is a legal requirement in order > to allow you to process credit card details. > > You won't have to encrypt the password against the username of whoever > has access to it. Just encrypt it the once, and use the DBMS side of > things to manage access rights. Maybe use a couple of fields in the DB > to store the credit card number in two versions, one that is two-way > encrypted, the second that is one-way. You can set up your web system to > only have access to the one-way version, meaning that the actual number > can't be got by that user. The two-way encrypted version would be > accessible only by a specific second DB user, the access details of > which could change when personnel changes. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > 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? 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.") However, I'd strongly recommend letting a payment gateway do the heavy lifting. You let the payment gateway store the credit card details, and when you want to process another transaction for a visitor, you use the id for the visitor that's stored in your DB (if they already have set up an account) to process the request. For example, this type of scheme is documented at Rackspace (PDF): http://cloudsites.rackspacecloud.com/index.php/Can_I_host_a_PCI_compliant_site_on_Cloud_Sites%3F Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
From: Peter Lind on 30 May 2010 06:43 On 30 May 2010 07:49, Paul M Foster <paulf(a)quillandmouse.com> wrote: > This question is for people who take and store credit card information > for customers. > > Credit card companies, in an attempt to lessen fraud, are tightening the > screws on merchants who take credit cards. One aspect of this is a > requirement to store credit card information from customers encrypted. > > So let's say you have a customer whose credit card you keep on file, > because they'll be charging other items with you. The credit card > companies would like you to store this information with strong > encryption, which in their mind is one-way encryption. > > Now let's say that the credit card number is part of the customer > record. When looking at the customer record, you see just the last four > digits of the card. But when editing the record or when printing out > reports of things which must be charged, you will see the whole number. > Assume the users of the system have logins and passwords. > > 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. This > would be quite in addition to their username and password. Moreover for > this to be as secure as the credit card companies would like it, > whatever "password" is used would need to be changed frequently, > particularly at any change of personnel. This means you'd have to > re-encrypt all the credit card numbers using the new "password" every > few months or when you fire someone who had access to the data. > > This seems like an excessively cumbersome solution. Is this seriously > the way it's done? 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? Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 </hype>
From: tedd on 30 May 2010 10:50
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 |