X-Cart and PCI DSS / PA-DSS compliance

xplorer · #1 03-06-2009, 05:57 AM

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,

exsecror · #2 03-06-2009, 06:12 AM

How much of that section will be encrypted? We're in the process of writing an eBillMe (BillMeLater cousin) module into our cart to start accepting that form of payment. We also already have extensive modifications done to payment_cc and payment_ccend to have hooks into our system.

geckoday · #3 03-06-2009, 06:31 AM

Very good news. Thanks for responding so quickly to this issue.

I vote for no Zend/Ioncube encryption. I bought X-Cart because I get 100% of the source and don't have to run encoded programs. Several years ago ionCube had incompatibilities with Zend and took many sites down that used encoding (other software, not X-Cart). I don't need those kind of headaches. I also need to be able to use the X-Cart code as a base if I choose to use a gateway not supported by X-Cart - that's part of the faster development leverage you get when you buy a product that gives you source code.

exsecror · #4 03-06-2009, 06:32 AM

Quote:

Originally Posted by geckoday

I vote for no Zend/Ioncube encryption. I bought X-Cart because I get 100% of the source and don't have to run encoded programs.

I agree 100% with this, last thing I want is to have to throw out all the code we've been working on to integrate eBillMe for our next refit

SMDStudios · #5 03-06-2009, 07:23 AM

Good news here....

bigredseo · #6 03-06-2009, 07:56 AM

Because there's certificate involved in exactly how the process works, I'm sure SOME of it would have to be encoded just so that actions by users wouldn't circumvent the certification itself. The purpose of the certification is so that they can verify that it's secure and whatever, if it's opensource and anyone can access the code and modify it, then essentially EACH OF US would need to get re-certified that the process is still doing what it was originally designed to do.

At least, that's what I would think anyway?

kulture · #7 03-06-2009, 08:51 AM

How nice. Now how about doing the same for Litecommerce. It is modular after all and so it should be possible.

exsecror · #8 03-06-2009, 08:53 AM

Quote:

Originally Posted by handsonwebhosting

Because there's certificate involved in exactly how the process works, I'm sure SOME of it would have to be encoded just so that actions by users wouldn't circumvent the certification itself. The purpose of the certification is so that they can verify that it's secure and whatever, if it's opensource and anyone can access the code and modify it, then essentially EACH OF US would need to get re-certified that the process is still doing what it was originally designed to do.

At least, that's what I would think anyway?

Well as long as they do it that way I'm fine but if it hinders my ability to implement new payment methods (e.g. I shouldn't have to pay qualiteam to do it when our IT staff is more than capable of writing the code) then I will have a problem with it.

JWait · #9 03-07-2009, 05:02 AM

Quote:

Originally Posted by xplorer

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

Will this be in addition to, or instead of making X-Cart 5.0 PA-DSS certified?

geckoday · #10 03-07-2009, 09:16 AM

Quote:

Originally Posted by handsonwebhosting

Because there's certificate involved in exactly how the process works, I'm sure SOME of it would have to be encoded just so that actions by users wouldn't circumvent the certification itself. The purpose of the certification is so that they can verify that it's secure and whatever, if it's opensource and anyone can access the code and modify it, then essentially EACH OF US would need to get re-certified that the process is still doing what it was originally designed to do.

At least, that's what I would think anyway?

The intent of PA-DSS is to facilitate/allow PCI-DSS compliance by merchants not to force/enforce it. Therefore PA-DSS does not require encoding the software so it can't be modified. PA-DSS only requires the vendor to develop their software in a PCI-DSS compliant manner. Any modifications would be custom development for that one merhcant and as such those modifications would not be subject to PA-DSS. Custom developed payment applications fall under the merchants PCI-DSS assessment. For most of us smaller merchants that means we would need to attest in our self assessment questionnaire that we followed PCI-DSS guidelines in developing our modifications and no outside verification would be required. That's the same thing that PA-DSS is doing for vendors - making sure they follow PCI-DSS guidelines in developing their software. PA-DSS requires that vendors get outside certification because their application will be used by many merchants and magnifies the impact of insecure development.

Another example of how PA-DSS only facilitates compliance and does not mean that a vendor must prevent you from shooting yourself in the foot and implementing their software in a non-PCI-DSS compliant manner. PA-DSS only requires that the vendors software *can* be implemented to be PCI-DSS compliant and the vendor has documented for the user how to implement it securely. IOW, its ok for the application to have the an option to store CVV numbers. But the documentation with the application has to tell the user that option must be turned off to be PCI-DSS compliant.