cancel
Showing results for 
Search instead for 
Did you mean: 

SHA-512 in Perl

Our authorize.net processing is done in some OLD perl cgi code - any perl programmers out there?

 

We are trying to convert to the SHA-512 hashing.  Our current processing uses MD5, via the perl module Digest::MD5.

I use LWP::UserAgent to POST directly to the secure.authorize.net gateway transact dll URL.

What I get returned is an array of values. The MD5 hash is currently in the 38th array element. Authorize.net has been unable to tell me where I can find the returned SHA-512 hash value to compare to what I am generating in the program.

 

For my test:

I changed it to use Digest::SHA for the hashing. I generated the signature key and have it stored in hex in our database.  

 

 

my $sha512_string = '^' . $auth_net_login_id . '^' . $tranid . '^' . $grandtotal . '^';


my $key = pack 'H*', $sig_key;  ##to convert the store hex value to binary - as recommended here


my $sha512 = Digest::SHA->new;
my $sent_sha512_hash = $sha512->hmac_sha512($sha512_string, $key);

 

When I display that value, it just shows a bunch of weird characters on the screen - I don't know if that's expected or not. I am only displaying it to compare to what comes from authorize.net.

 

When the values are returned from Authorize.net (in the array), I display all the elements. There is a value in element 68 that looks like a hex value but that isn't what is in the hash that I generated.

 

So, isn't the hash returned from Authorize.net in the array? If not, then how do I obtain it using the methods we currently have in place? I don't consider this as using the API.   Or is the problem that I am hashing it wrong on my end?

 

I obtained the perl code for our current processing via Authorize.net MANY years ago from one of their perl customers. It has worked fine ever since. I do not have the knowledge, experience or brain power to change the whole process, unless someone could provide all the perl code (I know that's asking a lot). I also have a general knowlege of php but unfortunately the examples on this forum are too different from our perl process to be able to correlate the two.

 

I hope someone can help!   Thanks in advance!

 

smorrow123
Contributor
76 REPLIES 76
There is no code going to authorize validation thus far in AIM. We only have the coming back verification. The AIM guide says this is a redundant security check which echos what I’ve said the whole time about the modern API security check.

But since it’s been done thus far by the business and because there have already been a million hours invested in this might want to try just a bit longer. They have some use for it I would presume.

I’m seeing various syntax for Perl being posted here. I’m seeing strings that are concatenated with dots and quotes and strings that are not.

I am in agreement that this is an AIM integration. That’s why there are three response codes. I’m learning quite a bit about soon to be buried integration methods that I do not use from this hash exercise. I’ll find a use for it I’m sure.

Given that this is AIM, there is only the verification coming back and not the verification going in. And that would be a way to confirm for sure @smorrow123- when you did md5, were you creating a fingerprint going in? If not then it’s AIM. The sha512 mirrors the md5 process from all the docs I’ve looked at.

To provide better clarity here is an update to all my prior post.

 

My method is "relay response" read link below

 

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

 

Changes I used when posting the form to authorize.net

 

use Digest::SHA qw(hmac_sha512_hex);
$x_amount = "1.00"; # test amount
$x_login = "login id here";
$signature_key = "test signature key here";
$signature_key = pack("H*", $signature_key);
$x_fp_sequence = int(rand 5000) + 1000; # Some random number
$x_fp_timestamp = time();
$hmac_data = $x_login . "^" . $x_fp_sequence . "^" . $x_fp_timestamp . "^" . $x_amount . "^";
$x_fp_hash = hmac_sha512_hex($hmac_data,$signature_key);
...

Changes I used to process reply back from authorize.net

 

use Digest::SHA qw(hmac_sha512_hex);
$signature_key = "test Signature key here"; $signature_key = pack("H*", $signature_key); $data = qq~^$response{x_trans_id}^$response{x_test_request}^$response{x_response_code}^$response{x_auth_code}^$response{x_cvv2_resp_code}^$response{x_cavv_response}^$response{x_avs_code}^$response{x_method}^$response{x_account_number}^$response{x_amount}^$response{x_company}^$response{x_first_name}^$response{x_last_name}^$response{x_address}^$response{x_city}^$response{x_state}^$response{x_zip}^$response{x_country}^$response{x_phone}^$response{x_fax}^$response{x_email}^$response{x_ship_to_company}^$response{x_ship_to_first_name}^$response{x_ship_to_last_name}^$response{x_ship_to_address}^$response{x_ship_to_city}^$response{x_ship_to_state}^$response{x_ship_to_zip}^$response{x_ship_to_country}^$response{x_invoice_num}^~; $hash = hmac_sha512_hex($data,$signature_key); $hash = uc($hash); if ($response{x_SHA2_Hash} eq $hash) { ...

@Renaissance

Yeah, I think you’ve got me on the right track with the 3 fields based on the updated documentation and using the AIM method. It has truly been a group effort. I will try tomorrow.  

And the data being sent has always worked, so I’m sure there is no verification on the send. 

The SHA is a bit different from the MD5.  The MD5 text field was the first field in the data string that was being hashed with the MD5 method. But with the SHA,  the hex value signature key is converted to binary and used as a key separate from the hashed values. 

BUT I really think we’re on the right track with what is being done and what I need to change (30 values down to 3 with correct hashing) - I just can’t test it out now. 

I’ll post tomorrow with the results.

 

I don't want to discourage you form implementing a security feature you think is needed. However, take a look a https://support.authorize.net/s/article/What-is-the-MD5-Hash-Security-feature-and-how-does-it-work - even authorize.net doesn't think it's needed for AIM

 

If you are indeed using AIM, you may be spending a lot of time on something not really needed, you could probably just comment out the part of your code that validates the hash.

 

If you are using AIM the path forward, as others have said, is to move to a more up to date API. Althought this is perhaps not the forum to say it, there are other companies with secure APIs that are much easier to use, and offer better support. 70 plus posts, mostly of people exchanging their ignorance, and not a single post from authorize.net says it all.

@Renaissance @jgoebel @airman81

 

Ok, I am officially crying uncle. 

@Renaissance - I decided to go back one more time tonight - and set up the string with the login (I am not showing actual value below, but did use the correct one), trans ID (0 for tests) and amount as follows:

^theloginid^0^39.00^

I converted the sig key to binary and did the SHA hashing with that data string and the converted key. It still does not match the returned SHA hash. 

 

I am taking the advice given and just eliminate the hash check completely. That is with the assumption that when they actually do away with the MD5 hash and only have SHA-512, that they won’t then require that hashing be checked.

 

As stated before, I will suggest that my soon-to-be ex-employer look for a PERL programmer who can implement the API into our existing Perl programs. After all of this running around and spinning wheels for what should be a simple change, I have no confidence that I could follow the Authorize.net documentation and implement the API in the week I have left.  The other possibility also suggested by @jgoebel would be to tell them to find another authorizing company with an easier-to-use API and some support. ANY support would be better than the ZERO help from Authorize.net. 

 

I can’t mark this thread as “solved” or mark any one post as the solution, except maybe the @jgoebel post that suggested I just get rid of the hash check. BUT I DO want to mark this thread as closed, so I don’t have to continue to follow after I’m no longer using the email address that notifies me of posts. If someone can help me get it closed out, I would appreciate it. I’m new to the forum and don’t know the ins-and-outs.

 

Thanks to all of you who stayed with me and tried over and over to help. You all rock!

@smorrow123

 

You made a valiant effort and the cost/benefit of implementing this definitely has passed the breakeven point. Please disregard what I sent you earlier. Typing on a phone will eliminate line breaks, apparently. 

 

I hope the beaches stay sunny for you. And the islands, and wherever else you venture when you officially leave fun exercises like this behind. 

LWP is also used by me using Perl andMySQL. Nothing worked for you when you were using the POST METHOD. I couldn't use the MySQL SHA2 Function or the HEX AND UNHEX function. I have over 100 counties and towns that resist changes the same way they resist a plague. I am willing to pay anyone who can help me with the code. That's right, Thx

captainjhoni
Member