PrestaShop PCI PA-DSS payment gateway/bridge

[jimmer5]

https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true

Search on PrestaShop and nothing is returned.

 

Believe me, I've been through the 12 commandments of PCI SAQ D and if you aren't writing the code yourself at stating you follow all the appropriate procedures and protections, you have to use a PA-DSS approved payment application.

 

How does one use PrestaShop and accept credit cards and maintain PCI compliance?

 

Are PrestaShop payment modules created such that the card number never crosses any of the PrestaShop software itself? Is the customer taken off the PrestaShop software to an external payment gateway such that my server will never see a card number?

 

Unlke one of PrestaShop's big competitors, I'm finding little to read on PrestaShop and PCI. Is there a PCI link somewhere on the PrestaShop site?

 

 

Thank You.

[El Patron]

Most of PCI is handled by hosting configuration, i.e. you files run on one server db on another, as just one requirement among others that are typically handled server side.  Sorry not loads of time https://www.liquidweb.com/services/security/pci-compliance.html

[jimmer5]

Oh my goodness.... not at all. Those online merchants where cards flow through their enviornment must conform to PCI SAQ D which is far more involved than you state it to be. But of particular importance is the payment application, that part of the software that communicates credit cards to processors. For example I see an authorize.net payment module by PrestaShop and it uses AIM which is the authorize.net Advanced Intengration Method and thereforce you program to the authorize.net AIM payment API. Is the PrestaShop authorize.net payment module PA-DSS certified? If not, how does a merchant using it answer such questions on the PCI SAQ?

 

What is PrestaShop's response to something like:

http://magento.com/resources/pci

 

These are incredibly important questions to be answered for anyone considering PrestaShop and must conform to PCI SAQ D.

[El Patron]

I've asked fellow community member bellini13 to join.  I've no immediate goals in this arena aas my last look at pcs under the hood is a bit 'dated' but not irrelevant.   I'll follow along.

[jimmer5]

Thanks, I'm reasonably PCI-literate having had to fill out SAQ D for an environment in which we manage the hosted environment and custom software. We're looking to move away from some of the custom software and take advantage of something like a PrestaShop or Magento. I'm tackling the investigation from the security and PCI side so I am asking these questions with the best of intent in terms of my analysis of PrestaShop and PCI conformity.

 

More information:

https://www.pcisecuritystandards.org/security_standards/glossary.php#P

Payment Application:

In the context of PA-DSS, a software application that stores, processes, or transmits cardholder data as part of authorization or settlement, where the payment application is sold, distributed, or licensed to third parties. Refer to PA-DSS Program Guide for details.

 

So a Payment Application is any software through which the card flows that is of a commercial variety or licensed. Not a custom piece of software one would write on one's own, but licensed as licensing PrestaShop and any relevant payment modules.

 

Then further:

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/If-a-merchant-develops-an-application-that-runs-on-a-consumer-s-device-e-g-smartphone-tablet-or-laptop-that-is-used-to-accept-payment-card-data-what-are-the-merchant-s-obligations-regarding-PCI-DSS-and-PA-DSS-for-that-application/?q=what+is+a+payment+application&l=en_US&fs=Search&pn=1

which would involve software written by someone through which card information flows. Now if this is custom software that I wrote, then I can attest to the fact that it was developed according to PCI DSS standards. But if it is not software which I wrote, then I can't attest to its development and therefore in order to claim compliance I must be able to indicate that the payment application conforms to PCI DSS. In other words is the payment application PA-DSS validated and the only way I know of confirming that is to search for the payment application here:

https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true

[bellini13]

Prestashop does have a database table that would allow the capture and storage of a card information in the database, however there are no payment modules that are packaged with Prestashop that would utilize it.  That would be immediate failure of PCI compliance

 

With PCI compliance you have to think about it in the following structure

1) Your hosting environment

Does the hosting environment software and configuration comply with the rules.  This is things like apache, php, mysql, nginx etc...  For example, have weak ciphers been disabled, has openssl been updated/patched for poodle etc...  It would also extend to firewalls, be it hardware or software, and the ports that are open

 

2) Your eCommerce software

This could be any e-commerce package like Prestashop, Magento, OSCommerce etc...  and the software included in it, like themes, modules etc...  Do they allow cross site scripting, code injection etc...

 

3) Your Payment Provider

There are payment services like Stripe or Braintree (there are many others too), which offload the handling/capturing of card information to their servers using javascript, iframes and other client side (browser) technology.  With these solutions, the card details never reach your server, and Stripe/Braintree claim to be PCI compliant, taking much of the burden off of you the merchant.

 

There are also gateways which host a redirect payment solution, where the customer is redirected away from your store to their secure hosted environment to process payment.  This shields you from a lot of the PCI compliance rules as your hosting environment will never see or know the card information.

 

Then there are gateways that allow you to capture the card information, and send it to them securely using server to server technology.  Since the card information crosses your hosting environment, this would bring you into scope of PCI compliance rules.  Even if you do not store the card information, simply crossing your hosting environment puts you into scope.

 

4) Your Payment Module

Now in order to accept payments in Prestashop, you need a payment module.  There are modules like Offline Credit Card that allow you to capture the card details from the customer, store them in your database, and process them in your POS terminal or other payment solution after the order is created.  This is probably the worst thing you could do if you are looking to pass PCI compliance on any sort of small business budget.  You are fully exposed in this model and will likely fail all PCI compliance testing in a shared hosting environment, using Prestshop.  You will probably fail in a VPS and dedicated server environment too, unless you know how to harden these environments or your hosting provider has PCI compliance templates that can harden them.  Most will fail simply because the database (mysql) server is located on the same server as the webserver, and is accessible over the internet, that is immediate failure because the card data would be stored there.

 

There are a few payment modules (mine included) that implement the Stripe/Braintree payment solution, and are probably the fastest way to start accepting credit cards on your website.  They do require that you have a valid business in your place of domicile.

[jimmer5]

Thanks for the helpful response, ok... so I fall into the area you outline as:

"Then there are gateways that allow you to capture the card information, and send it to them securely using server to server technology.  Since the card information crosses your hosting environment, this would bring you into scope of PCI compliance rules.  Even if you do not store the card information, simply crossing your hosting environment puts you into scope."

 

So, current scenario environment as you define above... SAQ D where card crosses the server environment. Dedicated hosting with proper security zone network segmentation and firewalled and we've gone through the 12 PCI DSS Requirements using various log and traffic watching sources such as AlertLogic and employing WAFs and all the other PCI measures including the enormous amount of documentation. Yes we understand it and yes it is daunting. We believe we are fairly confident in what we are doing there at least as much as anyone else that has had to go through SAQ D, and yes, it is beyond reasonable for a small business. We have tech professionals in house and contracted as needed.

 

So current scenario, no card storage in terms of plaintext or encrypted... tokenization, but we maintain a cryptographic hash of the card number for the purpose of fraud prevention. We are in a business that heavily attracts fraud. Yes, there are outsource services for fraud prevention, but most are not as good as what our inhouse staff can do. Part of that is the ability to maintain card usage history. PCI allows storage of a cryptographic hash of the card number if you store in plaintext no more than the last 4 digits of the card, so that is something I would want to maintain with a migration to PrestaShop.

 

So, are you saying in such a scenario we would be writing or contracting with a company (perhaps such as yours) to develop a payment module that would do such a thing? Extend the PrestaShop database to mantain a card hash... say a SHA2 along with other customizations that fit our business model? At that point the PrestaShop module is custom and written by someone who is assumed to understand PCI programming practices such as OWASP and others, but at that point the module need not be PA-DSS validated since it is not licensed or mass-distributed.

 

Are we getting to be on the same page?

[bellini13]

I don't want to mislead you in anyway, I am not overly knowledgeable with all aspects of PCI compliance.  With that said...

 

1) Do you already have a payment provider and module for Prestashop?  If not, who is the payment processor, and do they have an integration guide or API specification?

2) As for storing the hash, you might be able to just use the existing database table, if the column size is large enough.  If not, creating a new column, or even a different database table to store the hash and key back to the order would not be overly complex.

[jimmer5]

You're more PCI-knowing than most.

 

1. I currently do not use PrestaShop. Current environment is custom code but I'm considering a move to PrestaShop or other open source solution. Basically want to take advantage of all the front end bells and whistles that would take in house developers a long time to reproduce. For the purpose of discussion, payment gateway would be authorize.net and likely via the authorize.net AIM API.

 

2. I've been looking for some good reading on extending/customizing the PrestaShop database in terms of either adding fields to existing tables or new tables. Much of what I've read suggests editing what looks to me to be core modules and I know that can't be a good idea. Can you point to some good reading on that, please?

[bellini13]

There are a few auth.net modules that exist, perhaps these do what you are looking to, or at least do most of it, and then your developers could finish up.

http://addons.prestashop.com/en/payments-gateways-prestashop-modules/4423-authorizenet.html

http://www.presto-changeo.com/en/payment-modules/28-authorizenet-payment.html

 

Prestashop uses a Object module (Active Record pattern) that maps database tables to PHP classes.  So if you have a database table named Customer with a column for first name, then you have a PHP class named Customer, with a variable firstName.  The Object model deals with updating records for you (unless you have complex mapping logic to perform).

 

I'm not aware of any specific documentation that will instruct you on how to properly use this.  But I can say you won't need to update core modules for most of the existing database tables, unless those tables support a core module (like the wishlist block).  Adding new database tables to capture your own data should be handled via your own custom module.

[jimmer5]

With regard to a payment module like:

http://addons.prestashop.com/en/payments-gateways-prestashop-modules/4423-authorizenet.html

What would you make of the statement in the bullets of that page that state "Safe and secure (PCI-DSS compliant)". Note they do not state PA-DSS validated.

 

This module would clearly be a Payment Application according to PCI and according to:

https://www.pcisecuritystandards.org/pdfs/pci_pa-dss_faqs.pdf

would qualify as follows:

Q. What types of payment applications are subject to the PA-DSS requirements?

A. Payment applications that are sold, distributed or licensed to third parties and are installed “off the shelf” without much customization by software vendors are subject to the PA-DSS requirements.

 

I didn't write the payment module, PrestaShop did so what does PrestaShop's statement of 'PCI-DSS compliant mean? As far as I can see from:

https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true

there is no listing for PrestaShop payment modules. So, I don't know who is attesting to the payment module being PCI compliant.

 

If I didn't write the code and I have no PCI documentation from PrestaShop backing the PCI compliancy of the payment application, how can I attest to anything about it in my own PCI documentation unless I examine the code myself and attest to it.

 

How much have you been invovled with assisting PCI SAQ D merchants make use of PrestaShop?

[bellini13]

Prestashop will never provide you with a certificate of compliance, no matter what their sales people and documentation say.  I've seen too many people complain on this forum about that topic.

 

I can't speak to the compliance of these payment modules, I'm only trying to make you aware that these modules exist and it would be easier to purchase one that gets you 80% of the way there, and you can have your developers finish the remainder.

 

I don't think there is an easy way out for you with the decision to use auth.net and allow the card info to flow through your environment. 

 

I use Braintree (and Stripe before that), and getting approved took about 3 days.  no PCI compliance certificates required.  I realize you want your staff to do fraud checks, but you can still do that without having the data flow through your environment.

[jimmer5]

Well... those are absolutely legitimate complaints about the lack of PA-DSS validation on the PrestaShop developed payment module.

 

I will add though, that I believe PCI leaves the whole PA-DSS subject intentionally vague.

 

For example, the SAQ D has a section 2D before you get into the 12 Requirements sections about if you use a payment application and if it is PA-DSS Listed? You state if you use one and if it is listed, but no indication of consequences or compliancy if you state that you use a payment application that is not listed.

 

But, I'd be cautious of using a payment module that was not developed in house to which I could attest and was not listed as PA-DSS.

 

I would agree though that if using authorize.net payment gateway and if need customizations it would be worth starting with something that already exists. Although I'd then be attesting to code we didn't write so it would have to be examined.

 

What did you mean by you use BrainTree and no PCI certificates required? I didn't follow that.

 

As far as the in-house fraud prevention... I want to maintain a card history via a SHA2 hash. How can I do that without seeing the plaintext card in memory, hashing it and then storing that hash? I don't see how the card can't cross my environment if I'm going to store a hash on it or make other in-house fraud decisions.

[bellini13]

What did you mean by you use BrainTree and no PCI certificates required? I didn't follow that.

 

I just mean I did not have to answer questionaires, attest to compliance, or show proof that my software, hardware environments are 'compliant'.

 

As far as the in-house fraud prevention... I want to maintain a card history via a SHA2 hash. How can I do that without seeing the plaintext card in memory, hashing it and then storing that hash? I don't see how the card can't cross my environment if I'm going to store a hash on it or make other in-house fraud decisions.

 

Capture the hash in the client browser and send the hash to your server

[jimmer5]

 

I just mean I did not have to answer questionaires, attest to compliance, or show proof that my software, hardware environments are 'compliant'.

In order to do what? Sell payment modules or accept credit card payments for Bellini Services? Any merchant accepting cards as a form of payment fall into one of these sections for PCI SAQ:

https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf

 

 

 

Capture the hash in the client browser and send the hash to your server

That could work if I assume all my customers will have javascript enabled, and then what decision has to be made if js is disabled and no hash arrives. This assumes, of course, one can effectively shop on a PrestaShop store without js enabled. I haven't played with PrestaShop enough to answer that.

 

But that is an interesting approach and might such a solution reduce your PCI SAQ status from SAQ D to SAQ A-EP?

That hashing js code which would be my js would have to have access to card number field which I would assume is generated by the payment module. Although that depends on what the payment module is doing as well.

 

In the payment modules for which you are familiar or wrote are they doing redirects to payment gateways which are then supplying the payment forms or are the payment modules receiving the card data and then posting it to the payment gateways? The later would I would say would most certainly imply SAQ D since the card data flows through my server in order to do the posts. Although the whole SAQ A and SAQ A-EP decision is still kind of fuzzy at least to me. The PCI Council in my opinion leaves a lot of these standards fuzzy and then it seems left to the interpretation of the 'field' then you have to read enough different A vs A-EP analysis write-ups to decide which one you believe you agree with.

 

I've seen some analysis state if you are doing redirects or iframes then SAQ A, if reposts then SAQ A-EP, but I don't think I agree with that, seems if the card at all crosses my servers, I'm SAQ D.

 

btw... I do appreciate the conversation we're having here in this thread. You are causing me to think from certain angles that I had not considered.

[Dh42]

Let me weigh in on this with my opinion. PCI compliance is a joke. It has always been a joke and really means nothing any more. Sure some people and some underwriters put a lot of trust in it, but is is misguided trust. Currently PCI is broken. There is no secure recommendation. From what I read a couple of months ago, and it could have changed in the mean time, there is no recommended cipher currently. So they basically say that security is broken and give no recommendation of how to come into compliance since there really is no compliant way.

 

 

That being said, you guys are talking about Authorize.net modules. They are as a compliant as the can be. Which again means nothing. The authorize.net module from PrestaShop is actually tested and certified by authorize.net. I found a couple major bugs in the module and the whole api a few years ago that they had to patch. Since it had to go back through Auth.net's Internal testing it took forever. Does it mean the module is PCI complaint? More than likely not. But at the same time the company looks at it and tests it out and certifies it for their gateway, so what does that mean?

 

 

Let's be frank, if your payment processor is drilling this they are wasting your time. An integration like PrestaShop has with authorize.net would require server access to get the credit card information or a man in the middle attack between your server and theirs. With either of those no gateway integration would ever stand up. 

[jimmer5]

Whether you agree with every one of the 12 commandments of PCI DSS or not doesn't really matter. In terms of accepting cards, it's the rules you play by. What do you think ecommerce sites probably looked like before PCI and having good security thrown in peoples' face. Would people even use VPNs and proper DMZ and other network segmentation if they weren't told to? Who knows. But, like I said.. it doesn't matter if you agree or not. They are the rules.

 

For the most part, I think the requirements are written pretty well, albeit in some cases left open to interpretation and yes in some, overboard. But even if you weren't taking payment cards, 75% of the requirements are sound security advise for any company with regards to IT. Go and try to apply for cybersecurity insurance, you'll see much of what's probably listed in the application is covered by PCI-DSS regs.

 

The requirements really only get updated maybe every 3 years so in some sense they have to remain generic. As far as ciphers, what would you like to be stated? Bitlengths can be specified, but do you want them to come out and say prioritize RC4 ciphers in your SSL configs because that helps defeat a Beast attack and then 6 months somebody realizes RC4 weaknesses are worse than Beast. Those regs have to be written so they are fluid and dynamic with the changing vulnerability environment. Good gosh, just look back at 2014, that was most certainly the year of the vulnerability.

 

What do you mean by "certifies it for their gateway" with regard to the PrestaShop authorize.net payment module?

So are you saying authorize.net will provide some sort of PCI Attestation regarding the PrestaShop payment modules? Off hand, I don't know what that would be, as I don't think a Service Provider Attestation would make sense. But again, if I don't write the code and I don't examine it for all the PA-DSS regulations about writing payment modules, then how can use of  it be written in to a merchant's PCI Attestation? Just consider the problem in terms of versioning, I just don't see how that happens with out some sort of certification that the author adhered to PA-DSS. Granted if you are a programmer you can always examine the key pieces of a payment module for PA-DSS standards and attest to it yourself as if you had written it. I tend to think most merchants using such modules don't have programmers on staff.

 

Then as far as finding bugs, well gosh, what software doesn't have bugs? Adobe flash must come out with security updates once a month. You write the software with the best of intentions following proper security as best you can, bugs are bugs. Software that's passed a compliance audit can certainly still have bugs. You find them, you patch them and let people know. No different than every other piece of software.

 

Not having used the PrestaShop authorize.net payment module, give me some insight please as to how it works. Is it reposting data to authorize.net... eg with the authorize.net AIM API or is doing something much simpler and less card-centric like a redirect?

[Dh42]

The requirements are hobbled together without any real technical input from people in the industry. The requirements in my opinion are vague and do not carry much weight in the market place like that did 10 years ago. 

 

I mean really if you want to get down to the brass tacks of the whole situation auth.net is owned by one of the largest clearing houses, Visa. They have picked a few modules for PrestaShop and said use these with our gateway. And by certified, it is listed here http://www.authorize.net/solutions/merchantsolutions/merchantservices/certifiedsolutiondirectory/  

 

 

As far as the bug that was found, it allowed for payments to be forged, it was a pretty big bug for a gateway to have.

 

What are you investigating compliance for an insurance policy? What is your yearly transaction level? I might have someone I can refer you to. 

[jimmer5]

 

I mean really if you want to get down to the brass tacks of the whole situation auth.net is owned by one of the largest clearing houses, Visa. They have picked a few modules for PrestaShop and said use these with our gateway. And by certified, it is listed here http://www.authorize...utiondirectory/

 

I don't know what the word certified means on that site.

Read the disclaimer at the bottom of that page.

[Dh42]

I can see how that is confusing. There are so many platforms that I imagine that has to be said. I honestly would contact them and ask about it. What I can tell you that I know for sure is that they wrote a good part of the module. They also have the module submitted to them to verify the security in it before it is released. The compliance on their end is actually handled by a 3rd party company. Heck, I am pretty sure they actually pay for the module to be written and distributed with PrestaShop too. But I think anymore of the internal workings of the situation would need to be deferred to them. 

[jimmer5]

We're definitely getting into the "fuzzy" side of PCI which I definitely find as one of its problems. Lots of good advise, no doubt, but I admit, the whole PA-DSS seems to be left intentionally vague. For example, on several of the SAQs, you are asked if you use a payment app and if so, if it is listed as validated. But nothing I can see indicating the consequences of the PA not being validated.

 

Same kind of fuzziness with SAQ A vs SAQ A-EP.

 

Have you ever tried to figure those two out?

 

My take on them in terms of what I believe they are supposed to represent.

 

SAQ A - pretty much your whole ecommerce site is hosted and manged by a PCI compliant vendor.

 

SAQ A-EP - I believe redirects and iframes off to payment gateway for handling card information implies SAQ A-EP, but a lot of the documentation points differently, which I tend to think is a cop-out to prevent a lot of existing SAQ A customers from having to migrate to SAQ A-EP which is way more work. But that's my cynical opinion on that one.

 

SAQ D - everything else as in reposts.