After a bunch of researching, it's way more clear to me what's going on. There are several confusions regarding this, mainly for merchants still using Magento 1. These confusions arise from the fact that Magento 1 has two different Auth.net payment methods: "regular" auth.net, and Direct Post auth.net, while Magento 2 only offers the Direct Post method. Because of this new understanding, I completely changed the question that I originally asked, trying to make the situation more clear to anyone that encounters this. For a simplified overview of the situation, check Esco INC's answer bellow.
A merchant using Magento 1 and Auth.net payment method (not the same as Auth.net Direct Post method) has no way to update any configurations to stop using the md5_hash field that Auth.net will phase out. There's a possibility that this will break the transactions made from Magento to Auth.net, once Auth.net stops using md5_hash.
At this point it's not clear what needs to be done for merchants running Magento 1.9 and using the "non Direct Post" Auth.net payment method. This payment method has no configuration fields that can be updated to tackle Auth.net phasing out the MD5 hash. If we don't do anything, Auth.net's response will stop sending the md5_hash which will possibly break any transactions (this is not confirmed though). If we apply the patch it's advised to configure the "Signature Key" in Magento's admin, but the "non Direct Post" has no "Signature Key" field.
On March 28, Auth.net will deprecate the MD5 hash for their Direct Post API and their AIM API. After this date, stores that don't update their configurations won't be able to process auth.net transactions, that is, all purchases using this payment method will fail. Ref Link here
Magento 1 offers two different Auth.net payment methods: Auth.net and Auth.net Direct Post. The first one uses the AIM API, while the second uses the DPM API. Ref Link here
Magento's article about this change says that merchants that use the Direct Post method need to 1) apply a patch 2) get a new "Signature Key" at Auth.net and 3) update their Direct Post configuration with the new "Signature Key". Ref Link here
The article does not mention what to do for the "non Direct Post" auth.net payment method. This method's configuration does not have a "Signature Key" to set up. It does have a "Transaction Key", which is not the same as the "Signature Key" used in Direct Post. Ref Link here
Since the "non Direct Post" method uses the AIM API, which will also phase out MD5 hash, it's not clear what needs to be done for merchants using Magento 1 and the Auth.net "non Direct Post" method.
I can confirm that in the "non Direct Post" method, Auth.net's response includes an md5_hash field. I confirmed this by turning on the Debug Mode in the "non Direct Post" method at Magento's admin. This option creates a log of all the transactions with their request and response data. On every response there's a "md5_hash" field.
I ran the patch provided by Magento in a testing instance that uses only the "non Direct Post" method, but I got an error loading the checkout page (not making the actual purchase). Not sure why it's trying to parse a response from Auth.net since the purchase has not been made at this point. Error: Fatal error: Can't use method return value in write context in [path]../app/code/core/Mage/Authorizenet/Model/Directpost.php on line 391
Fix: Copy/paste this file:
At line 391 change
$hashConfigKey = !empty($response->getData('x_SHA2_Hash')) ? 'signature_key' : 'trans_md5';
$responseKey = $response->getData('x_SHA2_Hash'); $hashConfigKey = !empty($responseKey) ? 'signature_key' : 'trans_md5';
After this fix, the checkout page loads correctly, and transactions go through without problems.
Not sure how to proceed to confirm correct functionality or report additional issues. Until March 29th, we'll be monitoring the site, with special attention on the 28th, the date that Auth.net will completely phase out the MD5 hash. However if we do get a problem on that day, there's no information on what can be done.
Any help is appreciated.
I discussed with the author of this article in its comments section. He thinks this auth.net change won't affect this payment method.
Esco INC's answer bellow aligns to what the author of the article above point out, it's likely the non direct post method won't be affected by this change.
Update March 26
Seems like Auth.net updated the production change date to June 28. Check their article again