x_SHA2_Hash missing in silent post for void/refund transactions

[tchamness]

While converting some existing software to use the new hash method we encountered a problem where x_SHA2_Hash is not being populated in the silent post request when the transaction is voided or refunded.  It is populated as expected when the transaction is originally submitted.

I'm trying to determine whether this is a configuration issue, a bug, or intentional behavior?  Is anyone else able to replicate this behavior?

(This is on the sandbox environment)

Partial contents of the silent post for the original transaction:

'2019-03-12 3:05:52 pm UTC'
  array (
    'x_response_code' => '1',
    'x_response_reason_code' => '1',
    'x_response_reason_text' => 'This transaction has been approved.',
    'x_avs_code' => 'Y',
    'x_method' => 'CC',
    'x_card_type' => 'Visa',
    'x_account_number' => 'XXXX1111',
    'x_invoice_num' => '10488',
    'x_type' => 'auth_capture',
    'x_amount' => '11.00',
    'x_MD5_Hash' => '',
    'x_SHA2_Hash' => 'AF85966DFC3021C341CA3AF4FCBBC0E973E3AE810385B29AB7825A4265BAE59D5BC5299CCF1D2ABFA298D9FBED619513C012C9931261059E86634F26E09523D3',
    'x_cvv2_resp_code' => 'P',
    'x_cavv_response' => '2',
    'x_test_request' => 'false',
  ),
)

Partial contents of the silent post for the void:

'2019-03-12 3:06:38 pm UTC',
  array (
    'x_response_code' => '1',
    'x_response_reason_code' => '1',
    'x_response_reason_text' => 'This transaction has been approved.',
    'x_avs_code' => 'P',
    'x_method' => 'CC',
    'x_card_type' => 'Visa',
    'x_account_number' => 'XXXX1111',
    'x_invoice_num' => '10488',
    'x_type' => 'void',
    'x_amount' => '0.00',
    'x_MD5_Hash' => '',
    'x_SHA2_Hash' => '',
    'x_cvv2_resp_code' => '',
    'x_cavv_response' => '',
    'x_test_request' => 'false',
  ),
)

[Renaissance]

Can't say much about this one other than that for modern API integrations the hash comes back on everything. So it may well be a bug. If you have backend scripts executing for refunds and voids it's kind of an issue.  

[msykes]

I can confirm the exact same behaviour, whereas previously MD5 hashes had worked since my software only needed to monitor voids/refunds.

I'm using AIM for transactions which end up voided/refunded, if that helps.

[Renaissance]

@msykes

You are using Silent Post for AIM? I would simply disable hashing because you’re over a TLS encryption with AIM.

[msykes]

@Renaissance thanks for the reply, yes it is via AIM.

Do you mean disable hashing to receive a refund/void notice? I don't use hashing to send payment info of course, but I think some sort of verification would be prudent. This is for distributed software, so I can't take the risk on behalf of 1000s of individual clients.

Is this an official stance from a.net on security for handling silent posts from AIM or just a suggestion?

I do agree that it'd be hard to guess a transaction number for a specific booking (it's event ticket sales), so it might be a viable solution if a.net really doesn't provide sha hashes on purpose. I'd be recommending webhooks anyway since I've implemented them anyway.

[Renaissance]

@msykes

Not an official stance but the guide does say that it is a redundant security check. When you are over TLS you are encrypted. For sure webhooks are terrific. I don’t think anyone would not be using them if they knew how easy they are to set up and how well they work. I’m far past the point where I can count the number I have tested. Well over 1,000 for sure. Never had a failure from auth.net and had about 7 failures that were my servers fault. Never had a failure on a live site and haven’t had a single failure on my test remote server since moving to AWS many months ago.

[msykes]

@Renaissance could you point me to where it mentions being redundant? I'm curious.

I don't see how receiving a silent post vs. webhook for a void/refund is any different, therefore requiring a simple verification of ownership (MD5 would have been better than nothing!).

Yes, definitely I do agree that webhooks are the way to go, it's maybe 2-3 more clicks to set up.

[Renaissance]

@msykes 

It is in the previous version of the AIM developer guide. Refers to md5, which sha512 replaces. 

Here is an image. 

https://ibb.co/z21MQMm

With AIM, I believe you can capture the response from the API call. Have you considered this? Silent Post is what SIM/DPM users use, but I think a good number of the AIM folks use what they get directly from authorize when the transaction is submitted. That is why it is redundant. If you use Silent Post to process then it is not redundant. 

My hunch is that voids/refunds do not have an amount in the response and that is why the hash isn't calculated and returned.    

[msykes]

@Renaissance thanks.

Thing is, it'd make sense if you're INITIATING a void/refund server-side, but not if someone goes into the authorize.net cpanel and initiates it there, since the only way your server will know is via a silent post or webhook.

I'd still disagree that it's redundant, maybe MD5 over SHA but the fact that it's SSL/TLS doesn't matter given someone can ping your endpoint/listener either way. It's highly improbable they get the combination of transaction ID  with (in my case at least) an invoice ID matching our records anyway, but still...

Or am I missing something more obvious here?

The silent post provides an amount which is 0.00 for voided settlements, not sure about refunds, waiting on a test settlement to go through and see what happens.

[Renaissance]

@msykes

Not sure I follow how your software and you work together. You have a distributed ecommerce software, correct? And when you say they go into the cpanel, you mean your users? I am confused as to who needs the response. The way you word it, it almost sounds like you have third parties who use your software, and you yourself need to know the results of their transactions. So you are the developer, your customer is the merchant, and when the merchant initiates a refund or void for one of their customers, you need to get a response from auth.net. Is that the case? If so then for sure you need webhooks or silent post and the hash is not redundant.

I do not think the major concern is a rouge customer trying to hack your app to mark their order paid. I think the real threat is malicious requests that aim to compromise your application, either automated or flesh and blood person. You can be exposed to all kinds of security issues if you don’t block or frisk post data coming to your endpoint.

If you initiate a void server side then for you, the person initiating the void, it is redundant if over TLS. You are getting a direct HTTP response with a TLS handshake. If a third party needs notified then that person will need to have security measures on their endpoint.

https://docs.microsoft.com/en-us/windows/desktop/secauthn/tls-handshake-protocol

It is similarly redundant using modern API but the value is in the response so I verify everything too. Every extra layer of security helps, if the added layers are only at a cost of a few lines of code.