X-Cart forums

[geckoday]

Originally Posted by cautious

On the original issue: There is no need to encrypt software for PCI-DSS compliance - unless there is a hidden agenda to make difficult user mods and 3rd party mods.

That is correct. I don't know where vendors get the idea they need to do this. Its not very friendly to those of us who bought the software because they get the source code and can modify it.

Originally Posted by cautious

Regardless of whether or not the underlying software is obfuscated, if you save a customer's credit card # and the CVV/CVV2 then you're not compliant. I have read policies that claim security and therefore compliance because they claim to delete these data after 30 days from their database.

No, storing card numbers is allowed by both PCI-DSS and PA-DSS and storing CVV/CVV2 is allowed PRIOR TO AUTHORIZATION only. Any card data must be stored encrypted using strong key management and once the card is authorized CVV/CVV2 must be deleted using a secure deletion method (e.g. multiple overwrites). There are a lot more hoops to jump through if you choose to store card numbers. I wouldn't recommend any small merchant store card numbers as meeting the requirements is a significant undertaking.

[cautious]

I may be reading too much into the compliance requirements. My understanding is that, regardless of whether the stored data is encrypted or not, both numbers should not be stored together. The CVV should not be stored at all.

The idea is to use it live on demand. I mean, there should be no storage prior to authorization. Just use the number and the CVV to get the authorization, discard the cvv and optionally store the main# if the shop has the capacity to safeguard it and strongly encrypted. There is no need to ever store the cvv, it should be treated like the second part of a two factor authentication.

If both the cvv and main# are stored encrypted together prior to authorization, an attacker can steal the storage and apply brute force. And it'll be worth it because, for a big merchant, the reward is that the cracked storage will yield millions of complete cvv, main# pairs ready to use.

[geckoday]

Originally Posted by cautious

I may be reading too much into the compliance requirements. My understanding is that, regardless of whether the stored data is encrypted or not, both numbers should not be stored together. The CVV should not be stored at all.

You are reading too much into it. Take a look at PCI-DSS 1.2.1 on page 5, footnote 2. It says "Sensitive authentication data must not be stored after authorization (even if encrypted).". Sensitive data is defined as full magnetic stripe data, CAV2/CVC2/CVV2/CID and PIN/PIN Block. Its left open to store this data prior to authorization because of the big boys who use store and forward messaging systems to communicate with their backend systems that do the authorization for their other systems. In hanging out on PCI forums with QSA's its a common misconception that you can't store the CVV2 prior to authorization but the QSA's universally agree its acceptable. The QSA's say that the PCI-SSC, the group responsible for PCI-DSS and PA-DSS, has started a task force to look at security requirements prior to authorization but at this point PCI-DSS doesn't cover security prior to authorization.

Originally Posted by cautious

The idea is to use it live on demand. I mean, there should be no storage prior to authorization. Just use the number and the CVV to get the authorization, discard the cvv and optionally store the main# if the shop has the capacity to safeguard it and strongly encrypted. There is no need to ever store the cvv, it should be treated like the second part of a two factor authentication.

I agree this is the way merchants should operate but it is not mandated by the card brands, PCI-DSS or PA-DSS. All of the reasons to store CVV2 prior to authorization have better ways to deal with the problems.

Originally Posted by cautious

If both the cvv and main# are stored encrypted together prior to authorization, an attacker can steal the storage and apply brute force. And it'll be worth it because, for a big merchant, the reward is that the cracked storage will yield millions of complete cvv, main# pairs ready to use.

Not really an issue. If you use the encryption algorithms and key management practices required by PCI-DSS, brute force would take decades to crack the encryption.

[cautious]

Good info. Thanks.

My bad - that I always forget that there is always an exception for the big fish, for the "privilegeds".

But we have taken the advise of our IT to not emulate the big boys; therefore, we've taken the "best course of action is avoidance" approach. We never store the cvv (encrypted or not). The consequences/implications of this approach are these --- and they should be familiar with businesses that follow the same "avoidance" approach:

1. We do not take credit card #s over the phone anymore. So there is no danger that the numbers will be written down somewhere and not shredded after authorizing the charge via a virtual terminal. The customer in physical possession of her card is always in charge of authorizing the payment via the secure ssl channel we provide.

2. We do not have an exchange. Technically, we do; but not in the traditional sense. All of our exchanges are processed as Returns, meaning that we will process an exchange by first refunding any due amount. Then the customer, if he so wishes can purchase the replacement item himself with his card. Why?
Usually, our typical exchange is the customer wanting to get a replacement item that costs more than the original. The vitual terminal interface at our payment processor requires both the main# and the cvv to authorize payment. Since we did not store the cvv then we are stuck and unable to charge the customer the extra difference due to the replacement. But our gateway does not need cvv for the merchant to refund a card. Hence, we process the exchange by refunding the amount due. The customer who is in physical possession of both the card can then buy the replacement item and authorize it herself.

Again, good info. And thanks for sharing the expertise.

[robertswww]

PCI compliance: What it is and why it matters (Q&A with Bob Russo, general manager of the PCI Security Standards Council):

http://news.cnet.com/8301-27080_3-10448197-245.html?part=rss&subj=news&tag=2547-1_3-0-20

[ahk]

Originally Posted by BritSteve

I think the problem with redirecting or using an iframe is that xcart doesn't feed back the transaction result or the details to the cart. If this is the case, you would have to log in to the gateway, look for the result and either approve or decline the order.

Would be nice to get some clarification from xcart as to whether they support these methods.

Steve

Wait a minute - I thought X-Cart supported redirection to a gateway... is that not the case? If so, isn't an I-Frame is just showing this redirected page in a different way (as a window inside of the existing checkout page) - and (still if so), why would X-Cart need to operate any differently in how it physically processes the transaction?

If X-Cart supports the redirect gateway method at all, this seems like a reasonable solution to consider. I'm surprised there aren't more people talking about this.

Is this how X-Payments is going to work?? After all, isn't X-Payments essentially supposed to function as a 3rd party gateway, except somehow appear seamless? If so, how is it going to achieve it's seamless look...?

[freeportway]

Vyacheslav,

Bzzzzt... Wrong answer.

The encryption of the source code using ionCube / etc. has NOTHING, ZERO, NADA, ZILCH to do with PCI-DSS. I deal with PCI ALL DAY LONG...
I've never heard a company that does audits come back and say "Oh, you need to encrypt your source code..."
In fact, most of them never even look at the source code.

If other shopping carts (Magento for example are "PCI") and they are not encrypting their payment module(s), why do you need too? Very strange.

Unless you're going to sell that as an "add-on", thats my guess?

Encrypting of the source code has nothing to do with PCI protection. PCI is all about following the rules and standards.

You folks need to hire a an outside company that does PCI audits, have them go through X-Cart then have them explain to you what needs to be fixed.
For PCI compliancy its typically around HOW you're doing things not usually how the code is doing it.

This guessing game won't work, and certainly locking down the payment module has really NO merit towards PCI, you could still have a payment
module thats encrypted with ionCube still NOT be PCI.

Lastly, I'll ask what nobody else wants too...

How much will the payment module cost once its encrypted? I see no other reason to lock down the source code of part of X-Cart only to
be able to market it and sell it as the "PCI version" of the product and charging more.

Hopefully I'm wrong.

[robertswww]

Anyone using the Dydacomp Payment Processing Gateway, or the Dydacomp Mail Order Manager (M.O.M.)?

Dydacomp Payment Processing Gateway:
Card purchases can be approved/transacted in real time online through SiteLINK Ecommerce or from the order entry screen while the customer is on the phone. The payment gateway is PCI compliant and supports a broad range of payment solutions, all card types, card present and not present transactions, dynamic DBAs, purchasing card transactions, and more.
http://www.dydacomp.com/gateway-merchants.asp

Dydacomp Mail Order Manager (M.O.M.):
Mail Order Manager (M.O.M.) 7 is developed for use in a Payment Card Industry Data Security Standard (PCI DSS) compliant environment. Dydacomp follows the PCI Payment Application Data Security Standard (PA-DSS) and has undergone an independent third-party audit of our development processes as well as the M.O.M. application.
http://www.dydacomp.com/pci-compliance.asp

--- Other PCI Links of Interest ---

List of Validated Payment Applications:
https://www.pcisecuritystandards.org/security_standards/vpa/
Note: Click on the "Accept" button to see the full list
(362 Vendors, 710 Payment Applications listed on 36 pages... Click the "Export to Excel" link to get the full listing in a .xls file)

Encryption for PCI Compliance:
http://pcianswers.com/2007/05/01/encryption-for-pci-compliance/

[lbs_09]

Why doesn't x-cart support e-Select plus' hosted payment page? This would make it a lot simpler for a lot of Canadian stores, since Moneris/eSelect is one of the largest payment processors in Canada. It seems that support for the hosted payment page was dropped at some point - why? Is it possible to set it up anyway by having someone customize it?

I have to say that reading through this thread has given me a huge headache as a small store owner who is trying her best to fully understand all of this. I cannot afford to switch to another cart at this point so I'm stuck with whatever happens... where is X-Cart at with X-Payments?

[xplorer]

Originally Posted by lbs_09

Why doesn't x-cart support e-Select plus' hosted payment page? This would make it a lot simpler for a lot of Canadian stores, since Moneris/eSelect is one of the largest payment processors in Canada. It seems that support for the hosted payment page was dropped at some point - why? Is it possible to set it up anyway by having someone customize it?

eSelect Hosted Paypage API is supported in X-Cart since the 4.3 version.