Credit Card encryption
in [General]
|
From: Phpster on 31 May 2010 07:04 On May 31, 2010, at 1:24 AM, Paul M Foster <paulf(a)quillandmouse.com> wrote: > 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 > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > It sounds like a lot of the activity is subscription based, is that correct? Paypal does support that. I would suggest looking thru the oci guidelines if you haven't done so already. The point there are essential requirements and should be enough for you to judge if you can be compliant with the rules. Pci is a total PITA, and the fines are not worth it if you can't meet the requirements. Bastien Sent from my iPod
From: tedd on 31 May 2010 12:36 At 1:38 AM -0400 5/31/10, Paul M Foster wrote: >On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: > > > 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. *blink* "Not true" and "It depends" are conflicts in logic. Either what I said is "true" or it isn't -- and if what I said is "true" for some (as it is and I can prove it) then what I said is indeed "true". I'm curious, why say it's not "true" and then follow with "it depends"? It appears to me that you have your mind made-up and don't care to listen to our experiences and recommendations. That's Okay, but I'm simply telling you what I KNOW to be true. You may either accept what I have to say, or reject it, but to reply that what I say is "Not true" is somewhat offensive and confrontational. I hope you didn't mean it that way. :-) >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. Party true. What data are used in credit card transactions are the: name of the card holder, credit card number, expiration date, CCV number, and zip code. I have not dealt with any credit card processors that require the billing address -- they just use the zip code. Additionally, it is up to the client to determine the level of security they want. They *can* require that *all* information be correct before accepting a sale. The downside of not requiring *all* the data to be correct is that the rate the credit processor charges for the transaction rises. Simply and logically put, if you don't get all the information correct, then there is risk and that risk is passed on to the client via an elevated charge for processing -- look it up. The up-side of getting only the minimal data is getting a sale under a higher risk/rate -- that's the clients choice and they usually choose it. >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. You asked for opinions -- do what you want. :-) Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com
From: tedd on 31 May 2010 17:06 At 12:36 PM -0400 5/31/10, I wrote: >That's Okay, but I'm simply telling you what I KNOW to be true. You >may either accept what I have to say, or reject it, but to reply >that what I say is "Not true" is somewhat offensive and >confrontational. I hope you didn't mean it that way. :-) My apologies for taking what you said as I did and my reply -- it was wrong of me. I am sure you didn't mean anything offensive. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com
From: Waynn Lue on 31 May 2010 19:16 Billing Address (at least the street number) is used in conjunction with the zip code for AVS checks. On 5/31/10, tedd <tedd.sperling(a)gmail.com> wrote: > At 1:38 AM -0400 5/31/10, Paul M Foster wrote: >>On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: >> >> > 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. > > *blink* > > "Not true" and "It depends" are conflicts in logic. > > Either what I said is "true" or it isn't -- and if what I said is > "true" for some (as it is and I can prove it) then what I said is > indeed "true". > > I'm curious, why say it's not "true" and then follow with "it > depends"? It appears to me that you have your mind made-up and don't > care to listen to our experiences and recommendations. > > That's Okay, but I'm simply telling you what I KNOW to be true. You > may either accept what I have to say, or reject it, but to reply that > what I say is "Not true" is somewhat offensive and confrontational. I > hope you didn't mean it that way. :-) > > >>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. > > Party true. > > What data are used in credit card transactions are the: name of the > card holder, credit card number, expiration date, CCV number, and zip > code. I have not dealt with any credit card processors that require > the billing address -- they just use the zip code. Additionally, it > is up to the client to determine the level of security they want. > They *can* require that *all* information be correct before accepting > a sale. > > The downside of not requiring *all* the data to be correct is that > the rate the credit processor charges for the transaction rises. > Simply and logically put, if you don't get all the information > correct, then there is risk and that risk is passed on to the client > via an elevated charge for processing -- look it up. > > The up-side of getting only the minimal data is getting a sale under > a higher risk/rate -- that's the clients choice and they usually > choose it. > >>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. > > You asked for opinions -- do what you want. :-) > > 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 > > -- Sent from my mobile device
From: Paul M Foster on 31 May 2010 21:21
On Mon, May 31, 2010 at 12:36:55PM -0400, tedd wrote: > At 1:38 AM -0400 5/31/10, Paul M Foster wrote: >> On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: >> >> > 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. > > *blink* > > "Not true" and "It depends" are conflicts in logic. > > Either what I said is "true" or it isn't -- and if what I said is > "true" for some (as it is and I can prove it) then what I said is > indeed "true". > > I'm curious, why say it's not "true" and then follow with "it > depends"? It appears to me that you have your mind made-up and don't > care to listen to our experiences and recommendations. > > That's Okay, but I'm simply telling you what I KNOW to be true. You > may either accept what I have to say, or reject it, but to reply that > what I say is "Not true" is somewhat offensive and confrontational. I > hope you didn't mean it that way. :-) Okay, let me be precise, then. I have no idea whether "most credit processing agencies... require...." I haven't dealt with "most credit processing agencies", so I have no way of knowing. And in fact, I don't also know whether "holding that information for more than 24 hours can be a criminal offense...." This may be a criminal offense where you live, and it may be a criminal offense in Zambatootie as well. Since I'm not familiar with every jurisdiction, I can't vouch for where or when it is a criminal offense. I do know, however, that according to the PCI DSS FAQ, storing a credit card number is discouraged, but not disallowed. Given the proper cryptographic treatment, it is definitely allowed. This also jibes with the self-evaluation questionnaire which Level 4 merchants (like myself) must complete yearly. > > >> 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. > > Party true. > > What data are used in credit card transactions are the: name of the > card holder, credit card number, expiration date, CCV number, and zip > code. I have not dealt with any credit card processors that require > the billing address -- they just use the zip code. Additionally, it > is up to the client to determine the level of security they want. > They *can* require that *all* information be correct before accepting > a sale. When you say "client" in this context, what do you mean? The ultimate customer, the company issuing the credit card, the bank, the merchant service company? > > The downside of not requiring *all* the data to be correct is that > the rate the credit processor charges for the transaction rises. > Simply and logically put, if you don't get all the information > correct, then there is risk and that risk is passed on to the client > via an elevated charge for processing -- look it up. I have been told repeatedly by my merchant service company that my rates do not and will not rise, should my "verification information" be incorrect. I have been told repeatedly that the collection of this information is for *my* benefit, to lessen the chances of *me* being defrauded. > > The up-side of getting only the minimal data is getting a sale under > a higher risk/rate -- that's the clients choice and they usually > choose it. Again, I'm not sure the definition of client as you are using it. However, I am aware that MOTO merchants (those who take credit cards over the phone, etc. and never have a physical card), like myself, pay higher rates than those who swipe them. Part of the game. Paul -- Paul M. Foster |