X-Cart forums

[JWait]

We have been looking into this and what it appears like to me is that all versions of x-cart are not and can not be PCI-DSS compliant. The reason for this is that in x-cart you have the option to store credit card information, and this is a BIG no-no. Even if there is a "upgrade patch" it can be circumvented so that credit card information can still be stored.

For this reason, version 5 must not have the option to store credit card information and be developed in such a way that it never can store credit card information in order to be PCI-DSS compliant.

X-cart absolutely needs to make a "database upgrade patch" that works 100% correctly 100% of the time to convert older carts to version 5. Most people can handle re-designing their site if need be, but retaining their data is of the utmost importance.

Am I wrong about this?

[mfb]

Originally Posted by JWait

...
Am I wrong about this?

Partly, according to my interpretation.

As far as I can tell, you can store credit card number and expiration date, but the three or four digit code (CVV2/CVC) code cannot be stored. But, this data must be encrypted where it is stored.

You can be secure and NOT pass PCI-DSS or insecure and pass it.

See https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf (Warning: PDF), Myth #9

[geckoday]

Originally Posted by JWait

We have been looking into this and what it appears like to me is that all versions of x-cart are not and can not be PCI-DSS compliant. The reason for this is that in x-cart you have the option to store credit card information, and this is a BIG no-no. Even if there is a "upgrade patch" it can be circumvented so that credit card information can still be stored.

For this reason, version 5 must not have the option to store credit card information and be developed in such a way that it never can store credit card information in order to be PCI-DSS compliant.

X-cart absolutely needs to make a "database upgrade patch" that works 100% correctly 100% of the time to convert older carts to version 5. Most people can handle re-designing their site if need be, but retaining their data is of the utmost importance.

Am I wrong about this?

Yes, you are wrong about this. There is nothing in PCI-DSS or PA-DSS that prohibits the storage of credit card numbers. The PCI-DSS Requirements and Security Assessment Procedures document on page 4 has a table of what is acceptable to store and the requirements for storing it (e.g. encryption). Credit card number, cardholder name, and expiration date are listed as allowable to be stored with protection such as encryption. Even if it didn't allow storage, a system can be configurable as long as its configured to meet PCI-DSS requirements. For example, system can have configuration that allows it to store CVV codes (which is a BIG no-no). But as long as it is configured so that it doesn't all is OK with PCI-DSS.

Another thing to note is that PCI-DSS compliance is nothing that X-Cart can do - it is the merchant that must be PCI-DSS compliant as it includes many things with respect to the merchant environment such as anti-virus software, firewalls, etc. What Qualiteam can and is doing is splitting out the payment part of X-Cart and getting it certified as PA-DSS compliant. What PA-DSS compliance means is that it has passed testing showing that it can be implemented in a PCI-DSS compliant manner and includes instructions for the merchant to implement it in a PCI-DSS compliant manner. Its still up to the merchant to implement it properly. Qualiteam has said they will port the modified PA-DSS compliant payment module they are developing for version 5 back to the version 4 releases.

Although storing credit card numbers is allowed by PCI-DSS, I wouldn't recommend that small merchants do so. In fact, even the big boys are trying to eliminate the storage of credit card numbers. The PCI-DSS compliance hurdles needed for credit card number storage are just way too much for a small merchant and the liability in the event of a breach too great.

[JWait]

Originally Posted by geckoday

For example, system can have configuration that allows it to store CVV codes (which is a BIG no-no). But as long as it is configured so that it doesn't all is OK with PCI-DSS.

What I was trying to say is that because x-cart "can be" configured to store CVV codes as well as other credit card information it doesn't pass.

Stone Edge Order Manager doesn't pass for the same reason,

[geckoday]

Originally Posted by JWait

What I was trying to say is that because x-cart "can be" configured to store CVV codes as well as other credit card information it doesn't pass.

Stone Edge Order Manager doesn't pass for the same reason,

I understood that and its still wrong. Whether or not X-cart or Stone Edge can be configured to store anything has no bearing on passing PA-DSS or PCI-DSS. The fact that it can be configured not to store sensitive data and that the merchant configures it that way meets PA-DSS and PCI-DSS requirements.

PA-DSS only says that when implemented following the vendors documented PCI-DSS compliant configuration it can't store CVV codes. It doesn't say a thing about what can or can't be stored if you don't use the vendors documented configuration.

PCI-DSS only says the merchant can't store the CVV. It says nothing about the capability of the software the merchant is using to store it if one chooses to configure it that way. You just can't configure it that way and be compliant.

BTW, CVV is the only piece of data that X-Cart deals with that can't be stored under PA-DSS and PCI-DSS requirements. For Stone Edge it would be CVV and the mag stripe track data that can't be stored. Card number, expiration date and cardholder name are all acceptable to store as long as they are properly encrypted.

[JWait]

I don't mean to be obtuse here but going by what you say I take it to mean that all a shopping cart vendor has to do is be able to configure their cart to not process or save any credit card information to be in PCI-DSS / PA-DSS compliance. What the buyer of the shopping cart software does after that shouldn't affect the software vendor's compliance, only the software buyer's compliance. Since x-cart does that now, why isn't it compliant?

[geckoday]

Originally Posted by JWait

I don't mean to be obtuse here but going by what you say I take it to mean that all a shopping cart vendor has to do is be able to configure their cart to not process or save any credit card information to be in PCI-DSS / PA-DSS compliance. What the buyer of the shopping cart software does after that shouldn't affect the software vendor's compliance, only the software buyer's compliance. Since x-cart does that now, why isn't it compliant?

Well, sort of.

There are really three different compliance issues we are talking about:

1. PA-DSS compliance
2. VISA PA-DSS mandate compliance
3. PCI-DSS compliance

X-Cart is not required to be compliant with anything if it is not used as the payment application - i.e. if it doesn't store, process or transmit credit card numbers. So if it is configured to use Authorize.Net SIM, Paypal Payflow Link or other gateway where the credit card numbers go directly from the customer browser to the gateway then there is no need for it to be compliant with PA-DSS, your web server doesn't have to be configured to be PCI-DSS compliant and you will be exempt from the VISA PA-DSS mandate since you won't be using a vendor supplied payment application. So although its not compliant with PA-DSS it can be used without violating PCI-DSS standards or the VISA PA-DSS mandate.

But this is not how most people use X-Cart and other shopping cart software. Most people want a more integrated checkout process where there is no jump out to a form on a payment gateway web site and then back to their site. So they are using Authorize.Net AIM, Paypal Payflow Pro or another gateway API where the credit card number is sent to the X-Cart software which behind the scenes sends it along to the payment gateway. When you configure X-Cart this way it becomes your payment application and now compliance is required on all three fronts. This requires X-Cart to be PA-DSS compliant, you must configure X-Cart according to whatever configuration standards Qualiteam documents as part of their PA-DSS certification and your web server must be configured to be PCI-DSS compliant. This will make you compliant with the VISA PA-DSS mandate.

This is why PA-DSS compliance is an issue for a majority of X-Cart users. Essentially, PA-DSS certification ensures the software:

• Includes features required for PCI-DSS compliance, like encrypting credit card numbers using a strong encryption algorithm with good key management, logging access to payment data, etc.
• Won't prevent you from configuring your server environment in a PCI-DSS compliant manner such as requiring all users to log on as root or administrator.
• Includes documentation on how the merchant must configure the software for PCI-DSS compliance.

[cflsystems]

This is a nightmare. Of course speaking as a merchant. It is a whole different story if I am just a customer - I want this security from the sites I will be buying from

[nuvo]

Originally Posted by xplorer

Hi folks,

I know that PCI-DSS compliance is very important for many X-Cart users, so, I would like to announce our plans towards making X-Cart stores PCI-DSS compliant:

1. We release X-Cart 4.3
2. We develop a payment module for X-Cart 4.3 and X-Cart 5.0 and verify it by a PA-QSA; probably, the source code of the module will be encrypted with Zend/ionCube
3. X-Cart users disable its credit card processing functions (so, X-Cart becomes not a subject for PCI-DSS) and install the PA-DSS verified payment module that handles all the credit card stuff; we will distribute the module among existing X-Cart users for free
4. The payment module will be implemented in such a way that allows its use with X-Cart 4.1.x and 4.2.x (with moderate customization of X-Cart source code).
5. Third-parties developing integration modules for payment gateways, not supported by the verified payment module out of the box, will have to complete a PA-DSS audit themselves (that costs dozens of thousands USD annually) if the chosen gateway integration method is a subject for PCI-DSS rules.

Best regards,

What's the current status on the PA-DSS certified Authorize.net AIM payment module? Do you think it will be ready soon? You said in the thread that it should be ready in the next month or so?

[geckoday]

The PA-DSS compliant payment module has been moved out to January 2010. See http://www.x-cart.com/roadmap.html