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

@smorrow123

 

My use of Digest::SHA that is working for me

 

     use Digest::SHA qw(hmac_sha512_hex);
     $transaction_key = "my testing transaction key";
     $transaction_key = pack("H*", $transaction_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,$transaction_key);
     $hash = uc($hash);
     if ($response{x_SHA2_Hash} eq $hash) {
     ...

My steps are broken out line by line just so I see each step... Perl offers so many ways to write the same thing. $data is the value of the 30 fields in the required order.

@smorrow123,

I regret now not verifying 100% that you were using DPM. That was the concenus of everyone after I had asked you what integration method you used. To go all the way back to square one, I think I see the problem now.

Your original post appears to have been derived from my php working hash post. You are using php syntax in that string. The quotation marks around ^ that are typed as ‘^’ are used in php to indicate that the carets are part of a string. The dots are on each side of the variables are used to attach variable values in a string.

So to put it another way, those dots and quotation marks are not part of the string, they are merely there to let php know that it is a string.

In looking at the Perl code people are posting, it appears this syntax isn’t needed in Perl. So you would just type the carets and variables with no quotes or dots.
@airman81,

What @smorrow123 actually needs is a string of login, transid, and amount. Could you post a Perl syntax version of such a string?

The not knowing what integration method is being used, followed by the unverified assumption that @smorrow123 was using DPM combined with the total lack of documentation on AIM verification until just today has resulted in a goose chase.

@smorrow123,

I would try a syntactically correct Perl string with those 3 values in the right order, delimited by carets. Per the information that is on hand that is what should be correct.

If that doesn’t work on the first or second try I would stop right there and not even worry about it until the AIM guide is updated with the proper method. We may still be missing info and no use in any more shots in the dark at what it might be.

The whole point of this hashing is that shots in the dark will get a hit once every 7 quadrillion years. It’s completely hopeless until we have every piece of information you need.

I will try the 3 fields and see if it works. I’m no longer at my PC, so it will have to wait for tomorrow. 

 

To be honest, I didn’t know what method I was using (DPM, AIM, SIM) but the information in the SIM guide looked very much like my code so I went by that. Like I said, I was given the code by Authorize.net many many years ago and never completely understood what it was doing. I don’t remember who the person was who finally determined that I was using AIM, but I would really like to know how they determined that.  How do I know for sure which one I’m using?   

 

Thanks for hanging in there with me. I am SO tired I can’t key in one more line of code or run one more test. It will have to wait for tomorrow. I’m too old for this crap! :-)

@airman81

This matches what I’m doing (in terms of converting the hex sig key to binary and hashing the string). So, I’m going to say I’m doing that part correctly and will wait until I can once again try the 3 fields that some people say I should be using since they feel I’m using the AIM method (I have NO idea what method I’m using!!). I tried the 3 fields in the first place over 20 hours ago, but might have used the wrong syntax. So I will try again, and if that doesn’t work either, I’m getting rid of the hash check completely and moving on to my well-deserved retirement. 

Thanks!!

@Renaissance@smorrow123

 

To tell you the truth I can't say what method I'm using :) After reading this it appears I'm using "relay response"

 

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

 

I did not use any package or existing code set. I wrote all of my Perl code from scratch years ago.

 

My "relay response" solution only works using the 30 fields and never worked when I tried anything else.

 

NOTE: Not that it matters... but it would help in my examples if I named the signature key $signature_key instead of $transaction_key!

 

Anyway, this is some of my outbound code that works.

 

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

 

BTW: Has anyone else noticed payments NOT processing using MD5 in production mode?????

 

 

 

The gateway response is the key. If you are using DPM or SIM the response will be name value pairs. If you are using AIM the response will be a string which must be split into an array.

 

The response you posted previously was pretty clearly an AIM response.

 

If you are using AIM I repeat my previous question; why are you using a hash? The authorize.net AIM guide doesn't seem to think it very usefull or important.

@jgoebel

I’m using the hash because that was the code that was given to me years ago by Authorize.net. I didn’t understand what it was doing, but it worked. And they DO return the MD5 hash ( and now the SHA-512 hash) in the string that I split into an array (so I obviously am using AIM - only I didn’t know it) so I figure it’s best to check it. 

I realize that I can remove it and it will hopefully continue to work for a period of time - and that’s what I’m going to do if I can’t get this to work.   Just how long that “period of time” is, will be important to my soon-to-be ex-employers - so they know how much time they have to find a perl programmer who can implement the API into an existing perl script. 

Thanks.

@airman81

OK - your post prior to this made sense and as I replied, matched what I was doing in terms of the sig key to binary and hashing the text. Now you posted something different and included a time stamp and sequence, etc - and I don’t understand where that comes from. You’re using that in your hashing, and that’s the first time I’ve seen those fields mentioned. 

@smorrow123

 

My last code block was an example for building the form submission going TO authorize.net and NOT processing the response back as I posted earlier.