DPM/SIM Fingerprint Expiration - Yes/No Question

[Renaissance]

Hi,

I am helping someone with a SIM integration. I am upgrading them from md5 to sha512. The response validation needs to be updated within 10 days, but per this post-

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

The fingerprint also needs updated, although no end of life is explicitly given. I am prioritizing my work, and would like to know if the md5 fingerprint will still be accepted until at least 4/30/2019. 

Can someone on the authorize.net team answer with a quick yes/no? 

Thank you very much for your excellent products and support. 

[silentsky]

I'm in the same boat and can't find a clear answer for this either. We have some products that can still use SIM hosted forms, but it doesn't say anywhere if the changes to the transaction fingerprint will cut over at the same time as the changes to the relay response (Mar 28, 2019 as I write this). The closest thing I can find is on page 28 of the current SIM guide, which says this: 

Authorize.Net recommends the HMAC-SHA512 hashing algorithm for constructing the fingerprint. HMAC-MD5 is still supported but not recommended.

If that's true, it would appear that MD5 will still continue to work for the transaction fingerprint in SIM forms for the time being. But it would be nice to hear for sure from someone at Authorize.net. 

[Renaissance]

Yeah I saw that in the guide too. They will give an adequate heads up I’m sure. I have a pretty complex piece of content management software someone is asking me to update and was worried at first that I wouldn’t be able to get both pieces in time. I have it figured out now thankfully.

From what I have read they will keep taking both hashes and will recognize automatically based on the number of characters. An admin on here (I believe it was @RichardH) has said in another thread that fingerprints will be business as usual. To me it is a fine gesture for them to prioritize the response security upgrades over the fingerprint. The fingerprint is more to mitigate their security burden and the response validation is to protect their customers.

Hopefully one of the admin will chime in at some point but I think we’re good for a bit still.

[RichardH · Accepted solution]

Hello @Renaissance 

We would of course prefer that merchants upgrade from SIM to Accept Hosted.  That said, we're not currently aware of any plans to require HMAC-SHA512 at this time.

Authorize.Net recommends the HMAC-SHA512 hashing algorithm for constructing the fingerprint. HMAC-MD5 is still supported but not recommended.

Richard

[Renaissance]

@RichardH

Thank you. The accept hosted upgrade is coming. Right now this person just needs a band aid on their current site so that it will continue to work. I was originally worried that I may not be able to do both pieces due to the mess their current back end code is, but have it figured out now. Thanks again.

[staopix]

Has anyone actually tested calculating the response hash where some of the fileds contain none ASCII characters?

For example in one the address fields I have 

Sãu Paulo

When calculating the hash it never matches.

However my hash matches when the fields contain ASCII characters only.

How do I get round this issue? Our intergation is written in PHP.

[Renaissance]

@staopix


The solution I think would be to run the transaction and then pull it in an api call from authorize.net. That will let you see how it ends up in authorize.nets system. Have the response from the transaction dumped in a log file and compare what you get from the API call with the log file. My hunch is there is an encoding issue with the response. So you will have to see what kind of encoding is taking place and implement a sanitization process on your string to get it back to what authorize used to calculate the hash

[staopix]

@Renaissance 

Based off there example C# in the PDF they reference the ASCII encoding class. Whcih can be found here: https://docs.microsoft.com/en-us/dotnet/api/system.text.asciiencoding?view=netframework-4.7.2

based of the example in that documentation the soloution seems to be that if the character cannot be represented in ASCII the a ? will be used. Which is what I am seeing. However I have tried to do this in PHP and cannot get it to work.

And the response from the API has the correct encoding too. I think their hash algorithm on their server side is doing something unexpected to the multibyte chars and its a case of us trying to second guess it.

[Renaissance]

@staopix

I see what you are saying. I was also referring to url encoding. So you dump the response in raw form on a log file and it is exactly the same value as is submitted?

[Renaissance]

@staopix 

I just validated a sample API call with the address you listed. It is an encoding issue. If you find my post "Working php hash verification" and go to the last post on page 6, I post working SIM/DPM code.  If you amend that code to use this line:  

 $responseCheck = str_replace('%E3','ã',$anetResponse); 
$responseCheck = explode('&',$responseCheck);

It will work for your example.  You want to take out the non ASCII encoding before you explode into an array is the idea. Double check me on the syntax and variable names, as I cannot recall by memory my exact code but this should get you on your way.

The next, and probably a lot harder, step is to build a library of all the non ASCII characters being used and develop similar decoding/sanitization processes for them. May want to build a custom function if you have more than a few.