Authorize.Net MD5 Update 2019: Affecting Magento and other sites

You’ve probably received several emails by now from both Authorize.Net, possibly from Magento, and maybe even a critical alert in the Magento admin about some upcoming breaking changes with Authorize.Net.

In this article we’ll try to help you understand what’s going on and what needs to be done.

What’s happening to my site?

Authorize.Net is making a change on June 27, 2019 that affects sites utilizing Authorize.Net. This includes Magento stores depending on their specific Authorize.Net configuration. The change will

Magento has put out a patch for legacy Magento 1.x and Magento 2.x sites that fixes the issue before the June 27, 2019 deadline.

The Magento patch is relatively straightforward but it will require the attention of a developer to apply and test it. You may also be using a third-party extension, and that may have its own update from the third-party vendor that needs to be applied and tested.

If your site isn’t using Magento but still uses Authorize.Net for transactions, you may need to incorporate a custom change, which we can help analyze and determine any necessary steps.

Can you help me figure this out?

Contact us if you need help identifying if you will be affect on June 27, 2019 and assistance with applying the patch.

---

I’d like more details on this change

What’s an MD5 hash?

Authorize.Net is removing a feature of their API that helps with security called a “hash”. A hash is an algorithm that takes a bunch of data and reduces it to a standard fixed amount, typically used for secure verification.

This original hash that Authorize.Net used is the MD5 algorithm, published in 1992, and is used in conjunction with an HMAC. The HMAC process uses a secret key only known to the website and Authorize.Net so that the website can confirm the data it received is valid and from Authorize.Net.

How is the hash involved?

Typically when communicating with Authorize.Net’s API, it’s from the website to Authorize.Net using HTTPS, like your web browser uses when talking to your website during checkout. HTTPS provides the authenticity and confidentially thus the API hash verification isn’t of much benefit.

However, some API integration methods of Authorize.Net, such as the Direct Post Method, relies on Authorize.Net making a connection the website to update the result of the transaction, such as success or failure.

How does the hash keep my site secure?

It is also possible for a malicious actor to pretend to be Authorize.Net, which they could also update the result of the transaction to say success as a method of fraud. However, since the malicious actor does not know the shared hash secret, hash verification fails and the attempt to update the transaction status is rejected.

Computers have become much faster since then which has threatened the security of MD5 and so newer hashing algorithms have been created to stay ahead of that curve.

A couple years ago Authorize.Net added a new hash method using SHA2 (in this case specifically SHA512, a specific method in the SHA2 family), which was published in 2001. This worked alongside MD5 with Authorize.Net providing both.

How will this change affect my site?

On June 27, 2019, Authorize.Net will no longer be providing the MD5 hash and only providing the SHA2 hash.

Applications that were built to depend on the MD5 hash will no longer be able to verify the MD5 hash after that deadline. Because the hash verification is a vital step in ensuring your website is communicating with Authorize.Net server, the transaction process should fail.

If you’re running a Magento site and using the “Authorize.Net Direct Post Method” payment method, you will need to patch your site or switch to a different payment processor, such as Braintree or PayPal.

If your site should be verifying the hash, it will need to migrate to verifying the SHA2 hash before June 27, 2019.

---

I’m a Magento developer. What do I do?

If you’re using the stock Authorize.Net payment method you basically just need to apply the appropriate patch. There’s different methods of doing so though depending on which version of Magento and which method it was setup.

Magento 2.x via composer

The steps for handling applying this patch are relatively straightforward and are based off this guide: https://support.magento.com/hc/en-us/articles/360005484154-Create-a-patch-for-a-Magento-2-Composer-installation-from-a-GitHub-commit

We recommend taking this approach because it tracks the patch as part of the project and automatically applies it. This aides projects with multiple developers and avoids the patch being forgotten on deployments.

1. Create a “patches/composer” directory in your code’s root
2. composer require cweagans/composer-patches
3. Download the patch file into that dir and replace “vendor/magento/module-authorizenet/” references with an empty string
4. Update composer.json’s “extra” section with the stuff below (the section probably exists already so add the “patches” and “composer-exit..” keys)
5. composer -v install (verify the patch applied by checking the source code since the output is a little confusing)
6. composer update –lock (updates your composer.lock hash)
7. Test and commit/push

"extra": {
        "magento-force": "override",
        "composer-exit-on-patch-failure": true,
        "patches": {
            "magento/module-authorizenet": {
                "MAGETWO-AuthNetDPM: Authorize.Net Direct Post Method SHA2 verification.": "patches/composer/Auth.net.md5.composer-2019-02-27-11-51-12.patch"
            }
        }
    }

Magento 2.x via GitHub clone

In this case you probably cloned the magento repo from github and have all of the Magento code committed instead of in composer packages.

In this case, download the github version of the patch and use “git apply” to apply the patch. Test, commit/push.

Magento 1.x using Direct Post Method

You may not need to patch if you’re not using the “Direct Post Method” payment method. Check your store configuration to verify which method is being used. The Direct Post Method is recommended though due to its potentially lesser scope for PCI-DSS compliance.

The simplest is to download the PATCH_SUPEE-11085_CE_1.14.4.0_v1-2019-02-28-05-21-55.sh file from the “Release Archive” tab on the Magento Downloads page, or just this link: https://magento.com/tech-resources/download#download2280

Move that downloaded file to your project root and apply it via executing: “/bin/sh PATCH_SUPEE-11085_CE_1.14.4.0_v1-2019-02-28-05-21-55.sh”. Test, commit/push.

There’s been unofficial reports of issues with this patch. We’re still in the process of verifying this.

I have a custom site. What do I do?

This is more complex because it depends on your unique situation. You might not need to be verifying any hashes so you’re fine. Your site might be verifying the MD5 hash when it doesn’t need to. Or, your site might already be using the SHA2 hash.

You’ll need to engage with a developer to help you find out. One option that might be possible, after March 7th, you can test your site against the Authorize.Net sandbox and if nothing breaks, you probably don’t need to change anything before the June 27, 2019 deadline.

Now is a good time to review your Authorize.Net integration method

However, if your site is using a deprecated Authorize.Net integration method (SIM, AIM, CIM, DPM, etc.) then now is also a good time to begin the planning on updating the integration to one that is not deprecated. Either remaining with Authorize.Net or using a different payment processor.

The primary reason is that, much like the MD5 removal, the other integrations can be officially removed without much notice. Better to be on the safe side.

 

Source: endertech.com