Authorize.net emailed the following to all customers this week:

Authorize.Net is phasing out the MD5 based transHash element in favor of the SHA-256 based transHashSHA2. The setting in the Merchant Interface which controls the MD5 Hash option will be removed by the end of January 2019, and the transHash element will stop returning values at a later date to be determined.

We have identified that you have this feature configured and may be relying on MD5 based transHash in transaction responses for verifying the sender is Authorize.Net.

Please contact and work with your web developer or solutions provider to verify if you are still utilizing MD5 based hash and if still needed to move to SHA-256 hash via Signature Key.

Please refer your developer or solution provider to our Transaction Hash Upgrade Guide for more details and information on this change.

Does this affect the module?

Comments

DamienMcKenna created an issue. See original summary.

damienmckenna’s picture

I grepped the D7 codebase and couldn't find either "md5" or "transHash", so maybe the module is ok?

damienmckenna’s picture

I also grepped the 8.x-1.x codebase and it looks fine too.

drupalganesh’s picture

I have also received this email. Went through the documentation given, but no idea what exactly to be done.

Can someone tell me how can we know if we have used MD5 and where it is mentioned in ubercart setting?

Also does this change require custom code setting? (I don't think so, because this won't be the small change to make in ubercart module)

capellic’s picture

This is something I need to look into as well. This is the text of the email notice I received this week:

Authorize.Net is phasing out the MD5 hash, an older method used by shopping carts, payment modules and plugins to verify that transaction responses are genuine and from Authorize.Net. We have identified that you have this feature configured and may be relying on this older method.

Please contact your web developer or solutions provider and confirm if you are using an MD5-based hash. If so, you should begin plans for moving to SHA-512 hash via Signature Key.

The MD5 Hash will phase out in two phases:

Phase 1 - Starting later this month to early February 2019, we will remove ability to configure or update MD5 Hash setting in the Merchant Interface. There are no changes to the existing API response.

Phase 2 - Stop sending the MD5 Hash data element in the API response. This change will require that applications support the SHA-512 hash via signature key. Dates for phase 2 will be announced later but is expected in the next 2-3 months.

Please refer to our support article: MD5 Hash End of Life & Signature Key Replacement for more details and information on this change.
Thank you for your attention to this matter and for being an Authorize.Net merchant.

What isn't clear to me at first glance is whether this hash is something this module would produce or if it is generated through the Authorize.net admin interface to then plug into the module settings. More to come later when I've got the time.

allella’s picture

The What is the MD5 Hash Security feature, and how does it work? points out that this is optional, primarily for the SIM integration. That article references x_md5_hash as a response key.

A grep for x_md5_hash surfaces

  • modules/commerce_authnet_simdpm/commerce_authnet_simdpm.module
  • profiles/commerce_kickstart/modules/contrib/commerce_firstdata_gge4/plugins/component/hpp/CommerceFirstDataGGE4ComponentHPP.class.php

An installation I'm reviewing shows Authorize.net AIM at the active payment method in the Drupal admin (/admin/commerce/config/payment-methods)

AIM is separate from Authorize SIM / DPM based on the README.

I'm also curious if this hash change applies to AIM, or just SIM/DPM, or neither. My limited research shows no x_md5_hash code in the AIM specific module.

Another note, if you go to the Add Payment Method page (/admin/commerce/config/payment-methods/add) there are options for "Authorize.net AIM - Credit Card" and "Credit Card via Authorize.net". The later is related to SIM / DPM in modules/commerce_authnet_simdpm/commerce_authnet_simdpm.module

rszrama’s picture

Status: Active » Fixed

Thanks everyone for sharing their research here. I'd like to concur: this project does not make use of API response authentication, primarily because it does not utilize any payment API with asynchronous payment notifications. The Silent POST communications in the SIM / DPM module may need to be updated, but even looking at the most recent commits in that project, it appears to have been updated per #3025418: MD5 being phased out 1/31/2019 in favor of SHA-256.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.