Pci-Dss Compliance Impossible With Cs-Cart?

Like most of you, we have CS-Cart configured to transmit payment info to a third party processor. CS-Cart encrypts the data and does not store cardholder information. The processor is PA-DSS compliant.



Some carts such as X-Cart and Pinnacle Cart are actually PA-DSS compliant (as is Quickbooks, etc.) There was a thread from four years ago (and interestingly this topic doesn't seem to have come up since) that was a bit unclear about the following question:



If cardholder data is accepted in CS-Cart via the payment form then wouldn't CS-Cart itself need to be PA-DSS compliant in order for the merchant to be PCI-DSS compliant? This is why X-cart and Pinnacle (and others) have taken the time and expense to be PA-DSS certified software.



All Simbrisk has provided (that I could find) as far as PCI info is here:



Product :: Feature Tour :: PCI Compliance



The information here is general and somewhat ambiguous. The majority of the page is just high-level general info on PC compliance. It states:



“[color=#747C83]When the order processing is carried out, double protection is possible.”[/color]



I'm sure data is encrypted between the CS-Cart form and the processor. But is stating that data is encrypted and no cardholder data is stored on the webserver good enough to mee PCI-DSS compliance standards (assuming all other items are compliant), or is the merchan ineligible to be PCI-DSS compliant if the software that is presenting the payment form then transmitting the data to the processer (CS-Cart) is not PA-DSS certified compliant like the processor is?

This page, if correct, seems to indicate that PA-DSS certification for CS-Cart WOULD be required to be PCI-Compliant.



http://turnkeye.com/blog/pa-dss-compliance-faq



I'm surprised this has not been a much hotter topic here especially considering several high profile cardholder data breaches in the news in recent months and years!?



My experience has been that most smaller merchants aren't aware of PCI-DSS because their developers/consultant/banks for some reason haven't educated them. And I think they haven't educated them because who has every heard of a small merchant being fined for not being PCI Compliant? But this shouldn't be an excuse not to be compliant.

My processor requires that I annually go through a checklist. If I store CC data then that checklist is quite extensive. If not, it is still about 50 questions. At least in the US, anything processor that sits on top of First Data is required to annually certify each account whether it's an online account or a card-swipe account.



And then there's the “beyond DSS”…

I have a client that had a breach and their processor is requiring us to replace blowfish for encryption (it's 64bit so they say it's insecure) and to replace the salted/md5 password for similar reasons (though I believe the latter to be uneducated).



As long as any credit card info is held in a SESSION, card data will be stored on your server (just go look at any Incomplete order) even if only briefly. This would apply to Xcart and other's as well. I believe most QSA's understand that some temporary storage is needed in a stateless system like a web page. The question is whether the methods and environment are PCI/DSS compliant.



As I read the PCI spec, there was nothing about the degree of encryption, only that card holder data needed to be adequately encrypted if stored. But once you have a breach, your processor may make demands well in excess of that specified by PCI/DSS.

While I haven't examined the actual code, I was under the impression that if you are only using the third party payment option with CS-Cart, like Authorize.net, that CS-cart simply takes the card number submitted via a form and the form processing script simply encrypts the information and sends it to the processor. If the card number is stored in the database somewhere in this type of setup that would be news to me.



With PCI-DSS 3.0, you can only use the “short form” SAQ if everything takes place on the third party processor's website which includes the form where the user enters the card number. Since the payment form is in CS-Cart and the data has to be encrypted and transmitted by CS-Cart, then the set of assessment questions is no different than if you were actually storing the card data. However, in this particular case, any questions involving data storage would be marked as not applicable. Only the encryption questions would be applicable. Obviously if CS-Cart is actually storing the data somewhere it would be a different story.



This still doesn't address the PA-DSS requirement of CS-Cart in order to be PCI-DSS compliant. I believe the only solution other than for the company to pay to have it certified would be to make some modifications to the code so it would qualify as “custom software” and thereby could be evaluated on that basis. The home page says over 30,000 stores using CS-Cart so if it's not PA-DSS certified, then I think technically all those thousands of stores using the stock software would not be PCI compliant.



I find it puzzling that there isn't more participation in this thread for reasons I stated earlier. It almost has the feeling as if there are A LOT of people just “looking the other way” on this issue. But if technically, you can't be PCI-DSS compliant using CS-Cart due to lack of official PA-DSS compliance, I think this issue is HUGE! The fact that CS-Cart makes no clear statements about whether the software meets requirements for a merchant to be PCI-DSS compliant (assuming all other requirements are met) nor makes any statements about PA-DSS is very troubling to me. I feel as if this issue has mostly been side stepped by the developer and most of the user community seeing there's virtually only one discussion I could find on this in the past several years and with no clear conclusions!

card is sent via form and then put in session ($_SESSION['cart']). Payment processor is called. If processed, card data is removed (if so configured). If payment fails, card remains in session which is then stored in the DB till next page load or access by browser. Card data will remain in all “Incomplete” orders until the order itself is deleted.



Your concerns are valid and I think your assumptions about users are correct. In this year's questionnaire, I had to respond to all the detailed questions about network segmentation, encryption, etc. It's a royal pain. No wonder most people now choose to use an offboard processing agent.

Is the card data encrypted when stored in the database?



Seems to me, it would be a fairly easy mod to disable the code that is storing the card data. What functionality would be lost? The ability for customer service to go re-process the card and put the order through for the customer?

[quote]Is the card data encrypted when stored in the database?[/quote]

Yes, via blowfish. But it's only 64bit so most QSA's will say it's insecure. Also there is no key management built in, only the text version in the confg.local.php file.


[quote]Seems to me, it would be a fairly easy mod to disable the code that is storing the card data. What functionality would be lost? The ability for customer service to go re-process the card and put the order through for the customer?[/quote]

Yes, it's pretty simple to obscure all but the last-4. And yes, sometimes the failure is due to a merchant issue like exceeding a processor limit. Note that a Decline is NOT an Incomplete order and the normal processing of card holder data occurs on a Decline. The most common cause of an Incomplete is the lack of a callback from the processor to the site.

So we are just moving a few sites away from Click Cart Pro and one of them has been compromised apparently leading to an investigation (going to cost thousands). Sage Pay direct was in place and are now reverting to Sagepay Form.

It sounds as if it is highly risky then to take card payments on site at all without it being PA-DSS compliant?

So we are just moving a few sites away from Click Cart Pro and one of them has been compromised apparently leading to an investigation (going to cost thousands). Sage Pay direct was in place and are now reverting to Sagepay Form.

It sounds as if it is highly risky then to take card payments on site at all without it being PA-DSS compliant?

if you like chargebacks and large fines go for non compliance :)

PCI also says all data should be encrypted in communications too, not just in storage. Additionally if you are doing CS Cart on site payments its not just CS Cart you need to worry about, its the Linux server, other dependencies, physical security etc etc.

We changed to Stripe and we are no longer asked to fill out the PC compliance part.

Guess I should also mention that we use the "CS-Cart Stripe Payment Gateway" from Webkul. I have no idea if they have changed anything since we bought it but it works great for us. You have to use the pop-up or javascript to not throw up red flags on Stripe but it looks like the customer never leaves your site. You do still need an SSL but to be able to avoid the PCI stuff is nice. You still want to do everything you can to keep the rest of the customers info safe, but the PCI info you have to fill out with other merchant accounts is just annoying!