AIM Module - MD5 Hash Is Going Away. Is there an update?

[phi148]

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.   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.   **** I received the above in an email from authorize.net.  Just curious if anyone is planning on updating the module to support this?  More info here: https://developer.authorize.net/support/hash_upgrade/?utm_campaign=19Q2 MD5 Hash EOL Merchant&utm_medium=email&utm_source=Eloqua

[♥Dan Cole]

@phi148 Bill, I received that same notice but I'm not sure we need to do anything.  My AIM module doesn't have anything set in the MD5 option field so I don't think it is being used.  In any case we're lucky to have an authorize.net wizard on here so I'll summon him.  @John W  John what's your take on this?

Dan

 

[♥John W]

I didn't receive anything from A.net on this.  A quick read on those links talks about it for SIM and DPm.  I've always left the md5 blank but I noticed it does get a return in the debug emails.  I've thought in the past that the md5 was for SIM and DPM.  We'll have to look into this more. 

[♥John W]

I won't be able to deep dive into this right now, but the AIM method is now deprecated.  There's an upgrade guide.

https://developer.authorize.net/api/upgrade_guide/

 

[WIljen]

that is not good news as all the methods available for oscom are deprecated according to that post.

 

[phi148]

I always use the MD5 hash ... simply for added security.  It is optional.

However, as Wiljen and John stated above, this is not good news that AIM is now deprecated.   I was not aware of that.

We probably will survive for quite some time still... however, this will eventually bite us if we don't create a new OSC addon for the new authorize.net API

Edited January 12, 2019 by phi148

[WIljen]

so if we just blank that field it will cease using the MD5 hash and continue to work?  (at least for the time being) 

 

[♥Dan Cole]

Looks like everything will be handled via their API.  I got a survey request wanting to know what shopping cart software I was using.  osC was not even on the list.  Now that's not good. 😧

Dan

[♥Dan Cole]

13 minutes ago, WIljen said:

so if we just blank that field it will cease using the MD5 hash and continue to work?  (at least for the time being)  

 

I know it currently works without it but I don't know if it will continue to or not.   Sounds like we need a new module that works with their API.

Dan

[♥cannuck1964]

The CIM method has a lot of added functionality.  You can use it to save credit card data with authorize.net in a PCI safe manor, and subscription etc easily implemented.  I have built the CIM based system to save card info etc.  I will see if I have some time to put a package together, just that the extraction etc will take some work to do and not sure I have the time until after vacation and work load.  There are some class implementations if anyone wants to start it up on development:

https://github.com/stymiee/Authorize.Net-XML

cheers

Peter

 

[♥John W]

Hey Peter, CIM is listed as End of Life on the upgrade guide.

https://developer.authorize.net/api/upgrade_guide/

 

[♥cannuck1964]

6 minutes ago, John W said:

Hey Peter, CIM is listed as End of Life on the upgrade guide.

https://developer.authorize.net/api/upgrade_guide/

 

For hosted forms.   For XML it is the preferred method of implementation

The link I sent is for XML implementation classes

Hosted forms have not been in use for a very long time now.

cheers

Peter

 

 

[♥John W]

People might want to read this post below on the a.net support forum.   From what i remembed the md5 is only needed for SIm.  I've been searching through all the developer info and working on the forums.  It's been a long time since I poked around here.

Check this link

https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD5-to-HMAC-SHA512-and-how

 

[♥John W]

On my test site using my AIM module on their test server/sandbox it works with all the MD5 code commented out of the aim module.  I never had anything entered for it and all the md5 code was contingent on something being entered.  I think the md5 code was carry over from when Harald did the SIM module, but I'm guessing.

I also downloaded their SDK for the api and have played with that a little on my test site with Netbeans.  Netbeans is helpful because it parses the code and can take you right to a class or method without having to hunt for it.  Since they have about 500 files in this api, NB is really helpful.  I used their sample code to get it to work from my test site.  I think we could reuse a lot of the aim module code and convert it to use the api. 

[kamranisbest]

Any update about it. Did someone tried updating module with new hashing.

[Guest]

  Authorize sent this via email today. Apparently there is a bit more time to address this than might originally have been thought.

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.     Sincerely,  Authorize.Net

[♥John W]

I think all we have to do is remove the MD5 code.  Aim never needed this in the first place.  Of course, someone could contact A.net to verify. On my test account, I have removed the code and it works fine.  I never used MD5.

[kamranisbest]

I updated that with sha512. Now only issue remaining is i need certificate as for me ssl from authorize.net is not working. Can anyone help me with that. 

[kamranisbest]

Here is the modified file for your reference.

authorizenet_cc_aim.php

[♥John W]

You can get the current cert at this link.

https://github.com/AuthorizeNet/sdk-php/blob/master/lib/ssl/cert.pem

I think all we have to do is remove the MD5 code.  Aim never needed this in the first place.  Of course, someone could contact A.net to verify. On my test account, I have removed the code and it works fine.  I never used MD5.

[phi148]

I use the MD5 code and I highly suggest everybody else use the new method with the sha512 hash.  From a security perspective it is critical. 

Is security optional? Yes.  However, why wouldn’t you take the extra five minutes to implement this for you and your customers security?

[♥John W]

You can go search through the A.net info, but here's a piece of their info on md5.

" Note that the MD5 Hash option exists for transaction responses sent by means of the Advanced Integration Method (AIM) or the Card Present (CP) implementation methods. However, these methods use Secure Sockets Layer (SSL) to ensure that the transaction response is legitimate, and so it is not as useful for AIM or CP merchants. "

That comes from this link, but you can find several on their developer site.

https://support.authorize.net/s/article/What-is-the-MD5-Hash-Security-feature-and-how-does-it-work

[phi148]

Hi John,

Yes, SSL does provide security - but only between the client and the server.  It does not ensure the data itself traversing the SSL is accurate.  Hashing, encryption, etc.. protects the data itself from breaches and verifies the validity of said data.

Is it overkill? Probably... and again personal preference.  In my opinion, if the option to further validate my data is there, I'll take it.

Notice they say "not as useful for AIM or CP merchants".  If it was completely "not useful" then I imagine it would of been abandoned entirely.

 

 

[♥Gyakutsuki]

I have a question about AIM. When you make a transaction test, Do you see in the Authorinet the test transaction. I think it accepts only the live transaction ?

Could you confirm me ?

Thank

[♥John W]

When I use the test server, I use it in live mode.  It acts like the normal secure2 server, but in the sandbox.  I get a confirmation email and daily report just like secure sever. 

Someone said they had a problem with ssl also.  The secure sever is supposed be https://secure2.authorize.net/gateway/transact.dll  It has a 2 after secure and there are 3 instances.  A.net switched to the Akamai routing network a few years ago and the link was changed.  I don't know if they will keep the old active as they bounced back and forth on that.