Ready or not, here we come: the last days with Magento 1Enzo Perrotta
30 June 2020
Reading Time: 5 minutes
The moment has come: 12 years after its first appearance, Magento 1 has reached the end of life. What does this mean in practice?
After two years from the official announcement, Adobe will stop supporting this platform, and will no longer provide updates or fix any security issues.
Payment providers' reactions to this deadline are different. PayPal, for example, has informed their customers that after the date of June 30th, using Magento 1 can cause transactions to be processed incorrectly, or to simply fail.
On the other hand, MultiSafepay guarantees to process payments coming from Magento 1, provided specific strategies for the continuity of the platform's security are implemented (specifically, they require a subscription to the Mage-One program that they have partnered with).
Adyen recently released an updated version of its payment plugin that supports the use of the PayByLink method, which will be the only method accepted for stores running Magento 1.
The main common argument that all players raise is that Magento 1 eCommerce after June 30th, 2020 will no longer comply with PCI directives, in particular points 6.1 and 6.2, which concern the obligation of installing security patches within one month of release by the vendor.
By discontinuing support for Magento 1, Adobe will no longer release any security patches, automatically causing all Magento 1 installations to be no longer PCI-compliant.
However correct it may be, using PCI compliance as an argument seems to be rather forced since it's unlikely to be respected by all of the Magento installations that currently implement PayPal payments.
It would be sufficient for any platform, even the most modern, to have not installed the latest security patches, which would result in them not being compliant with the PCI requirements.
It must also be said that PCI compliance does not only concern shopping cart software.
It includes a series of directives that affect different aspects of an application, depending on whether the payment process is managed internally by the application or outsourced to another platform, such as PayPal.
In Self Assessment Questionnaire A (the more liberal one) for PCI compliance, some of the requirements relate to:
- the maintenance of secure systems and networks;
- support of a vulnerability management program (the notorious points 6.1 and 6.2);
- implementation of stringent control measures on data access (for example, who can access the servers).
The market share of Magento 1 gives a real insight into the size of the problem that the platform has. It is estimated that there are more than 150,000 active Magento 1 based internet shops, many of which probably will not be able to migrate to a different or updated platform in time.
And what about all the stores running Magento 2, specifically versions 2.0, 2.1 and 2.2? None of them are supported by Adobe anymore since September 2019, but nobody made any big announcements or looked concerned about PCI Compliance.
There is no question that an out-of-date application exposes both merchants and customers to enormous security risks.
One could argue that by not directly managing credit card payments on your site, but delegating the transaction to an external platform (for example, the PayPal hosted payment page), exempts online shops from being PCI compliant.
The reality is, a compromised platform behaves in unexpected ways: for instance, it can redirect the customer to a malicious checkout page, where credit card data can and will be be stolen.
So what can you do? Unfortunately, there are no quick fixes to get around these issues: migration to a new platform is inevitable, although it is possible to buy some time.
Get extended support for your current platform
The first step is to make sure that your version of Magento 1 continues to be updated, and this is possible in two ways:
- By relying on private entities (for example mage-one.com) that, for a monthly fee, ensures the constant release of security patches while they actively search for security holes in the platform;
- By migrating your Magento 1 platform to a version managed by the community, for example - OpenMage. It is necessary to underline that searching for bugs and vulnerabilities requires significant investment of time and money. OpenMage is open-source, thus, it is completely free to use.
It's important to keep in mind that both solutions will eventually lead to non-backwards-compatible changes in the originally released Magento code, which can cause some extensions to stop working, or they may behave in an unexpected way.
It is plausible that extension vendors will stop supporting their Magento 1 extensions as well, which opens up an additional critical problem, considering that 3rd-party modules can have vulnerabilities of their own, and are in fact one of the most common ways for hackers to hijack web applications.
Additional security measures
Another important step is to strengthen the control and monitoring of involved systems to prevent abnormal behavior through the actions of malicious users.
Some examples of processes to be implemented are:
- Secure the application behind a Web Application Firewall (WAF), which helps to block malicious requests. To name one, Cloudflare can act not only as a CDN, but it also offers web security features. ModSecurity may also come handy if you prefer a self-hosted solution.
- Activate an integrity control system over the application files. Many attacks aim to place malware files into the target application, causing it to behave in an unwanted way, though they continue to operate as expected by users.
- Implement active vulnerability checks: By constantly scanning our application against a database of known vulnerabilities, users can avoid nasty surprises. Services like Acunetix or Sucuri offer a comprehensive set of checks.
- Analyze the flow of logs from our application, especially if your application is distributed across multiple servers. Finding a needle in the haystack is much easier if you have the right tools up and running, which in turn makes it easier to detect potential issues as they occur. A powerful setup for this task is achievable with an Elasticsearch/Logstash/Kibana (ELK) stack, which is used respectively for storing, fetching, and visualizing log events.
Implementing the above falls within the field of Compensating Controls, or a series of procedures that are required to be documented when you are unable to adhere completely with with requirements for PCI compliance.
It should be noted that Compensating Controls are not a substitute for PCI compliance.
In the long run they can prove to be significantly more expensive than correcting compliance issues, but are needed where compliance cannot be reasonably achieved.
To underline, Compensating Controls refer to processes that should be in place in any secure environment.
Keep your software secure: it's always better to act, rather than react.
Sooner or later, migrating from a Magento 1 installation will become unavoidable, and replatforming will bring benefits in terms of security and performance. Moreover, it is an excellent occasion to review the store's functionality.
Consider also that migrating from Magento 1 doesn't mean a mandatory move to Magento 2. At Kiwee, we strongly believe that each business matches a specific platform: one may fit into a SaaS solution, like Shopify, others may need full control over the source code. Shopware 6 could be a good candidate.
If you still have doubts and would like to have our opinion on your current situation, let's get in touch!
Decided to migrate? Find how the User Journey Mapping can help you.
Read the options you have as your new eCommerce platform
Get aligned, with the PCI Quick Reference Guide
Explore Wazuh, a powerful Open Source Security Platform.