-
-
Notifications
You must be signed in to change notification settings - Fork 437
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PCI Compliance #975
Comments
My understanding of this situation regarding PCI-DSS compliance and Magento 1.9 EOL is that as long as you don't handle credit card details yourself by outsourcing to a fully compliant PCI-DSS vendor you don't need the full compliance. In Stripe's documentation it says for example that by using Stripe Elements you automatically qualify to the most basic level of PCI-DSS compliance SAQ A (which does not contain Requirement 6).
Regarding Paypal the default Magento integration redirects to Paypal's own website which means that the website never actually sees the payment details just the final payment token which should also make it SAQ A compliant. I only investigated the two specific payment methods that affect our business so I am not aware of how other payment integrations work. |
adding some more Links as of https://twitter.com/mbalparda/status/1262742228696395779 : also we should list Vendors, who post about it in a supportive way As this is a dynamic topic, we should add a dedicated Page to our Website for PCI, we can additionally publish a Blogpost when we reached enough content, to have it forward to News Websites |
> we should add a dedicated Page to our Website for PCI
I agree lets do this fast
…On Tue, May 19, 2020 at 3:56 PM Daniel Fahlke ***@***.***> wrote:
adding some more Links
as of https://twitter.com/mbalparda/status/1262742228696395779 :
https://www.pcisecuritystandards.org/documents/FAQs-for-PCI-Software-Security-Framework-v1_0.pdf
https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf
also we should list Vendors, who post about it in a supportive way
-
https://blog.onestepcheckout.com/2020/05/magento-1-store-payments-30th-june-2020-pci-compliance/
As this is a dynamic topic, we should add a dedicated Page to our Website
for PCI, we can additionally publish a Blogpost when we reached enough
content, to have it forward to News Websites
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#975 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE7I22G45AGDOU2NBCD7A3RSKFXNANCNFSM4NANNIPQ>
.
|
Adding a link: Self-Assessment Questionnaires Most merchants offering CC payments should be able to easily fulfill the SAQ-A requirements (no audits required). Anyway, a merchant should never store CC data or even get in touch with it (= SAQ-A). Thats in it's own interest. Things like recurring CC payments with tokenization are AFAIK not even a PCI compliance subject. That's up to the merchant to provide good enough security. I wasn't aware of fear mongering on that topic. So it would be nice to clearify that for merchants, and maybe also publish it via admin-notifications... |
https://www.paypal.com/us/smarthelp/article/faq4241 Paypal says:
Do we have to worry? Could it be that the use of "Paypal Express" is blocked? |
It seems unlikely that PayPal will do anything active against existing Magento 1 installations, they just won't officially support it. They already accept PayPal payments through many other EOL applications or those that do not have vendor support. In addition, they don't specifically state something to the effect of "you will no longer be able to receive payments using PayPal", but rather they say "your integration will be out of compliance" and are vague enough to make it sound scary. As long as a store is still taking active measures to remain secure, such as continuing to apply OpenMage patches and all the security measures they should have already been taking, it would remain in compliance with PCI. In the worst case you may have to contact PayPal and explain to them that the site is still being maintained in line with PCI requirements, but I personally see even that as unlikely. PayPal and Adobe have entered into an agreement for PayPal to offer loans to companies to upgrade to Magento 2 and it does seem like this messaging is designed to scare people into upgrading. As a side note, PayPal's own Magento 1 EOL announcement links to the Magento Association's EOL resources, which in turn links to the OpenMage project. |
Thanks @rossbearman, very clear for me now! |
If the OpenMage maintainers haven't already, it may be worth reaching out to Mage One about this, as they are also trying to get some clarification from both PayPal and VISA on this matter. (cc: @Schrank) |
I think we need to open a section on open mage and clarify dat we DO
provide patches. Almost every two days. And that the code IS maintained.
…On Thu, 21 May 2020 at 12:03, Ross Bearman ***@***.***> wrote:
If the OpenMage maintainers haven't already, it may be worth reaching out
to Mage One about this, as they are also trying to get some clarification
<https://mage-one.com/2020/05/15/open-letter-to-paypal-and-visa-about-the-end-of-life-of-the-magento-1-x-platform/>
from both PayPal and VISA on this matter.
(cc: @Schrank <https://github.com/Schrank>)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#975 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE7I23IWOJU3CI3LGJYWL3RST4AXANCNFSM4NANNIPQ>
.
|
Hey @rossbearman thanks for the mention. PCI is unfortunately a highly discussable field and the outcome is: A shop/merchant can be PCI compliant a software can not (that might be simplified until wrong, but I think you get the main point). We talked to a couple of experts, QSAs, etc. and the outcome is, only a QSA can tell you based on your single Magento website, whether you are compliant or not - and of course all of them are humans, this means, one QSA might accept OpenMage or MageOne but another doesn't. One accepts us, but not you and the other way around. So just stating that you are providing patches and therefore the shop is compliant is wrong. But I think one can argue, that you provide patches, therefore the Shop comply with 6.2 of PCI DSS. The big questions is: Is it enough for the QSA? Without having people actively searching for security vulnerabilities. MageOne (avoiding "we" here to not confuse with us here :-)) discussed in the beginning whether we partner up and share forces with OpenMage, but there are two reasons against:
PCI is an annoying topic. The Specifications of PCI DSS don't know about OSS and is unspecific with the definition of 'vendor', no one is able to tell you what to do on a generic software level to be compliant (read as: if you want to know whether you are compliant, you need an assessment for your store). We and you are giving our best to be part of the solution, hopefully this is enough. |
I think it'd be great to add a list of payment processors/gateways that have quality M1 extensions which allow for SAQ A compliance (not SAQ A-EP). That is, form fields are fully hosted (redirect or iframe), multi-use tokens (saved card), refunds supported, etc. It's a lot easier to switch payment processors than it is to re-platform! |
@ioweb-gr could you please move this question somewhere else? It does not belong into the topic of this issue, which is already big enough in context. |
One customer of ours received this email from Adyen yesterday:
We'll reply that we're switching to OpenMage. If this is enough for them fine, otherwise we'll switch to another payment provider. |
@mmenozzi Do you have reply from Adyen? |
Hi, sorry guys for the delay. Yes they replied... Here their response:
Note that in my message I also asked what about Magento 2.0, 2.1 and 2.2 which are already in EOL. They didn't reply to this question. And I cannot find any answer to this question elsewhere. |
We maintain system PCI compliance in the UK via nginx config. Our site undergoes regular penetration tests for this compliance. Maybe we can all agree a best practice Nginx config for LTS. |
@ollyboy I think a simple, secure, production-ready config would be great to provide, perhaps as an article on the webpage so that the user can customize it as they follow along? Docker-based of course. :) |
@ollyboy Can you share the config you have so far, please? Maybe the community can review it and work towards publishing it as an officially recommended best practice. |
@ollyboy yes interested in the setup. Also checkout magenx Magento nginx setup which is quite advanced and with security built in. We added some additions on top. Main item I’ve been watching out for is to create some honeypot for admin uris that are known for invulnerabilities and if they are requested then we know it’s a bad request - and send it to ban. |
Hi all. Here is nginx config. I have text replaced my clients name with [client]. You need to review any of the [...] strings and replace for your own use. This config is passing a UK penetration/PCI scan.
|
Some notes on this:
|
Regarding Stripe, using their latest module version - am I safe in PCI terms to use it with OpenMage, or do I need some asssessor checking my site?
|
Yes please. The more info we have the better. :) |
@ansgarbecker Ouch, if you're not already doing it, hiring a QSA will be a significant additional cost.. What Stripe extension are you using? I would suggest you have a backup plan for moving to a new processor (that doesn't require a QSA) and then trying the approach of "I am migrating to OpenMage LTS, please support it with your Magento 1 extension" and see if that is accepted. If you're using a third-party extension you could contact the extension developer and ask them to support OpenMage (no changes required, just a pledge really) and then that would be another good argument for OpenMage acceptance by Stripe. If you have a contact at Stripe it would be great to convince them to add OpenMage to the list of supported options for M1 users. |
@colinmollenhour we're using their official Stripe/Payment module latest version (v1.1.5 currently), from their download page. |
It looks like they've scrubbed the M1 extension from their help doc.. Please keep me posted on how it goes with the Stripe conversation or feel free to include me in it directly (colin.mollenhour@openamge.org). I see you're the author of HeidiSQL which I've used before, so thanks to you as well! :) |
Good news from Stripe payments provider:
|
@ansgarbecker That's awesome! EDIT: I see now there is a separate "tab" for Magento 1.. It would be great if there was an official mention of OpenMage on their EOL page or the Magento 1 tab, or if they added a new tab specifically for OpenMage since we are considering removing the Connect manager.. Or maybe this is a strong case for keeping it? (#903) |
I will be review this config and get back to you in the next few days. |
Can you please post your index.php? |
Index php interest too ;) Addition to nginx conf
|
@Adel-Magebinary and @seansan please see the PR #1209 which proposes a simple nginx config as the default dev environment. It is not meant to be production-ready per-se but I would like to create a simple "reference" config that users can use as a starting point for replacing Apache. This config uses a very simple and secure technique for controlling what static files are made public using a separate "/pub" directory rather than using the Magento root for static files. It also restricts all PHP requests to just index.php rather than allowing arbitrary fastcgi script filenames (avoids using Your additional WAF-like rules are a great reference, perhaps these could be added to "WAF rules cookbook" wiki page so users can pick and choose and customize easily? https://github.com/OpenMage/magento-lts/pull/1209/files#diff-9e3923f9fdb3de5d1849d1eca7869eb6R10 |
Looks good
I would add at least commented out section for htaccess protection of admin
(entrypoint for most if not all hackers)
And advise to review this: https://github.com/magenx/Magento-nginx-config
…On Mon, Sep 28, 2020 at 8:44 PM Colin Mollenhour ***@***.***> wrote:
@Adel-Magebinary <https://github.com/Adel-Magebinary> and @seansan
<https://github.com/seansan> please see the PR #1209
<#1209> which proposes a
simple nginx config as the default dev environment. It is not meant to be
production-ready per-se but I would like to create a simple "reference"
config that users can use as a starting point for replacing Apache.
This config uses a very simple and secure technique for controlling what
*static* files are made public using a separate "/pub" directory rather
than using the Magento root for static files. It also restricts all PHP
requests to *just* index.php rather than allowing arbitrary fastcgi
script filenames (avoids using $fastcgi_script_name). If your
deployment's source code is write-protected from the web server user it
should make it near impossible to ever run unauthorized PHP code without
the entire server first getting hacked.
Your additional WAF-like rules are a great reference, perhaps these could
be added to "WAF rules cookbook" wiki page so users can pick and choose and
customize easily?
https://github.com/OpenMage/magento-lts/pull/1209/files#diff-9e3923f9fdb3de5d1849d1eca7869eb6R10
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#975 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE7I25OUONHI2EUNK6SLJ3SIDKQXANCNFSM4NANNIPQ>
.
|
Thanks @seansan I'll check that out and consider adding htpasswd to the default. |
Looked at the index.php again as requested, can't really send as it's too client-specific and Cloudflare specific, you can switch between 15+ store views on this site, but we try to send new users to the most logical store. Most of the protection is done in Nginx, especially the include white CDN white list and then deny all other. The protection in index.php is about the final check of all _SERVER variables and avoiding any rubbish calls to Mage::run What it does:
... etc ... |
PCI and the future LTS is a great product, super stable and there are 10’s of thousands of businesses that don’t have the funds, time or focus to convert to magento2 in these troubled times. My view is 2021/22 is going to be very tough for small/medium businesses. My idea is to put together a project and offer that will “destroy” the arguments that magento1 is dead or non PCI compliant. Rough ideas for discussion to agree an “LTS 2030” plan
Some background info…. PCI DSS ( Data Security Standard ) considers merchants to be: Level 1
Validation Requirements: Level 2
Validation Requirements: Level 3
Validation Requirements: Level 4
Validation Requirements: What does PayPal say: Requirement 6 of the PCI DSS requires merchants to "develop and maintain secure systems and applications by installing applicable vendor-supplied security patches." Without future security patches, Magento 1 merchants will no longer be able to meet this requirement, which could result in costly and time-consuming remediation. This is not a PayPal-specific requirement. PCI DSS requirements apply to your integrations with card payment brands, such as Visa, MasterCard, American Express, Discover, JCB, and any other payment processor on the Magento 1 platform. Visa has stressed that urgent action is required for merchants to migrate from Magento 1 and advised merchants to be aware of their responsibilities in securing their environment to help prevent the loss of payment card data. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Although PCI Compliancy can be acquired by self assessment
and it is not "really" required in Europe (where I am from) becuase of GDPR regulations, and mainly only for CreditCard processing (if it happens on your site and not the PSPs site)
Howvever it would be good to make a statement on this and publically communicate LTS supports PCI Compliancy ...
https://docs.magento.com/m1/ee/user_guide/store-operations/compliance-pci.html
The text was updated successfully, but these errors were encountered: