Upgrading MD5 to new hash (SIM)

[cwdsl]

I am trying to upgrade from MD5 to the new hash method as described here:- https://developer.authorize.net/support/hash_upgrade

We are using SIM still do in addition I read the guide at https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD....  This second link seems to talk about generating the fingerprint with more values than the first link above does, more similar to how wo do MD5 currently.

I’m having trouble validating matching the value I submit to what is returned in the response.  Note: We need this to work with SIM as we can’t upgrade to the new API currently.

I am creating the hash using the new method and submitting it to the x_fp_hash during the post.  I assume my x_fp_hash is correct because I was previously getting error 99’s which is a fingerprint error, but no longer do.

The response comes back after doing the payment in the x_SHA2_Hash field.  It doesn't compare to x_fp_hash.  So I thought there is more to this.  Looking in the SIM guide, on page 73 at https://www.authorize.net/content/dam/authorize/documents/SIM_guide.pdf it mentions generating a hash from 30 fields.

I've done this and it still doesn't compare to x_SHA2_Hash.  So I assume I am doing something wrong, but not sure.  The documentation doesn't really give any examples of how to do this so I am uncertain what my issue is.

[Renaissance]

hex2bin works for sure. I’ve tested it numerous times.

[capturewiz]

For our DPM website, we used @stw's solution, instead of @Renaissance's, because Renaissance's requires the latest AuthorizeNet PHP library, which requires PHP version 5.6, which would require re-writing our entire website.

In step 1, stw's solution calls the PHP function base_convert, which did not work for us. Both hex2bin and pack worked. We used pack because hex2bin isn't available in our version of PHP.

Note that @stw's solution will fail in "2-3 months" because AuthorizeNet plans to stop sending the MD5 Hash in the API response:

https://support.authorize.net/s/article/MD5-Hash-End-of-Life-Signature-Key-Replacement

So we don't do this part of @stw's solution:

$response = new AuthorizeNetSIM($apiLoginID, $md5Setting);

Instead, we simply check if the transaction was approved, x_response_code === '1'.

Unfortunately, this exposes us to the risk of an imposter posing as AuthorizeNet.

So, to make the site a little harder to hack, we added a our own hash to an HTML hidden field, and check the value when it comes back in the AuthorizeNet API response. So while we can't be sure the response came from AuthorizeNet, we'll know if the custom hash came from our server.

[Renaissance]

@capturewiz, there is a second verification you can do with sha2 with the response. It involves a delimited string with 30 carets. It’s in the DPM guide. Quite a bit different than the fingerprint on the front end, but several have gotten it to work. I am 100% confident I could get it to work in 1 hour if I tried, but I don’t use that integration method.

[capturewiz]

Thanks @Renaissance, but it took @cwdsl so long to figure out that solution, and it's so complicated,  it scared me off. It took me a few days just to get @stw's far simpler solution to work :-(

[cwdsl]

@capturewiz, my implementation only took a little while because I was incorrectly reading in the 30 values that need to be compared for the x_SHA2_hash.  Overall the VB.NET sample for the SIM integration I did was relatively simple to do once I gathered information together.  Hopefully the sample I posted will help others, although I have no knowledge of PHP so can't help any further in that regard.

[dickey38]

Thank you very much!  I attempted to upgrade SIM for SHA512 by simple modifications to my old, working MD5 code, but got code 99 errors.  The fact that SIM documentation and upgrade documentation are inconsistent added to my consternation.  I adopted your code and now things are working as expected, at least in the sandbox.

I would add kudos if I could find a way to do that in this message window.

[Static_FX]

holy sh*tballs! thank you @stw ... your code got me going again!

I had to use pack() instead.. but I only needed this to work for like 1 more month! lol

Wish Authorize had waited till May to switch :)

[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.

[cwdsl]

@staopix, the same happens for me with my VB.NET solution.

When I look at the value for x_city by returning Request.Params("x_city") it outputs...

S�u Paulo

So the fact it is returning the ? character I don't actually know how we'd know what character was there.

[staopix]

@cwdsl

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 you are 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.