Calculating Verifiable HashResponse

[Simon]

I'm working on a form and we're trying to get get the postback hashresponse to match what I'm calculating, however everything I do can't seem to generate the proper sha1 hash, and I can't get it working.
So the final redirect url winds up with (SHA1)

[DomainName]/index.php?on=1403241635395841111&vg=0aa80907-7d86-4d65-a3b6-e675d10793a7&au=9cbd17&gn=e9f46fb6-9385-41a7-a693-dbd19066892e&hashresponse=ZGZjMzgxMjlmNDQxMzc4NGE3M2Y4ODc5NDZhOGJkNTk5NGJkODhmZQ==&RefID=website

so according to the documentation http://manual.clickandpledge.com/Por...PI_Information
my string to hash is "[XXXXXX][1403241635395841111][25]" (XXXXXX is our secret word and $25 is the donation)

So if I run that through the Hashcode function from the forums http://forums.clickandpledge.com/showthread.php?t=660
I Get a59f8244cd58b2ff552c2f94cce60aebeb037452

And when I run the returned hashresponse through it
I Get ccae39caa7af1e9096500ccdbb7546f39916bbff

Can you point me in the right direction as to what I'm missing?

[CnP.Support]

Good day Simon,

Here are the 2 issues with what you are doing:

1. The [25] should be [25.00] to include pennies. So please change it to include the period and 00
2. In the .NET example we show this but in the PHP it is missing - the Hashcode is also encoded in your reply to help with possible characters that may cause issue in the URL. You need to encode your hashcode before doing the comparison. You may want to use a site such as: http://www.base64decode.org/ for testing.

If you do the above two corrections then your hashcode will be: ZGZjMzgxMjlmNDQxMzc4NGE3M2Y4ODc5NDZhOGJkNTk5NGJkOD hmZQ==

which matches ours.

Test it and let us know if it works for you.

[Simon]

perfect that did it.
here's a small version of the PHP function for future reference that just accepts a string passed to it.

function hashcode($stringToParse){  return base64_encode(sha1(utf8_encode($stringToParse)));}

// and a sample to test against 

$hashResponseFromCP =  "OTgxY2JlZjJmMGJlY2FkMGU4NDczN2JjM2Y2MDUzY2Y3MTkzZWI3OA==";

// Our calculated String
$s = "[xxxxx][1403241635395841111][25.00]";
if (hashcode($s) == $hashResponseFromCP){
    echo "match";
}else{
    echo "nomatch";
}

Thanks.

[CnP.Support]

Thanks Simon,

I will have that added to the manual.

[Simon]

is something going on with the backend? The hashes that I'm getting back are matching only occasionally.
The hashes being passed back from portal.clickandpledge.com don't always end in the == yet my calculated hashes always do.
I've made a sample donation page here: https://kellpartners-sj--developer-e...nate?test=true

and that posts to a super simple processor page. http://kellpartners.com/development/testHashCode2.php

So far the passed hash code is has been valid ~15% of the time, and since my calculated hashes always look similar, yet the CP passed hash seems to be changing in length, I can only assume there's something going on in the backend that's calculating the CP hash? Because according the the SHA1 specification it always returns the same length hash.

[CnP.Support]

Hi Simon,

Strange - since this works well in our own codes.

How can your hash code always look similar? Don't you include the amount?

[SecurityCode][Order Number][Amount]

the hashcode uses the order number and the amount and as such it is not possible for it to always be the same. Even if the amount is the same the order number is always different so the hashcode has to, by design, be different each time.

Please post your order number so we can review the XML.

[Simon]

By 'Similar' I meant they're always returning the same length string(56 chars) that ends in == , and yes I am including the amount. Whereas the returned hashresponse sometimes doesn't end in == and the length of the hash seems to be changing randomly.

here's a couple samples of the responses I get and the hashes (2 that return 52 char hashes that don't work and 1 56 character hash that does) these have the ordernumber, secret code and amount in them so you can check as well.

http://kellpartners.com/development/testHashCode2.php?Amount=17&on=1404211124504441111&vg=8e806cad-f31b-4aa5-8155-ae745befa2c6&au=837136&gn=7a39a18d-0b34-4855-894f-76b23f8eba6c&hashresponse=ZTdhYjcwMjRiOWRlYzMxNThhNjdmOTc5ZDVmMTY5OTA5YWUyYTFk&RefID=Web

http://kellpartners.com/development/testHashCode2.php?Amount=65&on=1404181859539791111&vg=d92ac70c-67e5-4570-a285-3a73991f67b1&au=c01c91&gn=21e809f2-331a-4e9d-b4b4-d29d1d94d5ff&hashresponse=NjNiZDNiNTc5OTI2NmU2NjVmNmJjZmQ0Yjk2Y2FjMzJiY2I5MWI5&RefID=Web

And One that works where the returned hash from CP is the proper 56 characters long

http://kellpartners.com/development/testHashCode2.php?Amount=897&on=1404211146064211111&vg=347b5441-0a10-4366-8b59-e6794cf9bb62&au=530c70&gn=452d223a-ce23-4719-98dd-3b5de489adc8&hashresponse=NTQzNjdmODA1ZTJhN2QyOTg1MTgxNDE1NDM3YzdiZjFiNjNlY2FlOA==&RefID=Web

[geilt]

Problem Solved with Workaround. Invalid SHA Returned from CNP.

There is a problem. It has to do with Click and Pledge's Hash Implementation. Sometimes, it omits one 0 at random and leaves it as a blank, making it a 39 character string instead of 40.

This is possibly due to a coding bug as referenced here on msdn

I created a workaround for this issue, by finding and replacing each generated hash's 0's with blank spaces, creating an array of possible hashes and then checking the base64_decoded hash from CNP against the array of possibilities.

It's dirty but it works. There was no pattern I could find as to WHEN a 0 would go missing, but from what I have seen it only loses one 0. I assumed at first it was the last 0, but that was not the case.

<?php
function checkHashString($secret_key, $order_number, $amount, $receivedHash, $dump = false){
    $hash = base64_decode($receivedHash);
    echo strlen($hash);
    $sha = sha1(utf8_encode("[" . $secret_key . "][" . $order_number . "][" . $amount . "]"));
    $hashes = array($sha);
    $i = 0;
    while(strpos($sha, '0', $i) !== false ):
        $pos = strpos($sha, '0', $i);
        $hashes[] = substr_replace($sha, '', $pos, 1);
        $i = $pos + 1;
        echo $i;
    endwhile;
    if($dump):
        $dump = $hashes;
        $dump[] = $hash;
        echo '<pre>';
        print_r($dump);
        echo '</pre>';
    endif;
    return in_array($hash, $hashes);
}
?>

You can test with the following data:

<?php
    $results[] = checkHashString('letshashitout', 1406301520403881111, '50.00', 'MTkxOWJkMjU5YjIyODJiNTEyYTc1YTcxNzcxMmM2MTFhNGE0ZGEx');
    $results[] = checkHashString('test123', 1404211124504441111, '17.00', 'ZTdhYjcwMjRiOWRlYzMxNThhNjdmOTc5ZDVmMTY5OTA5YWUyYTFk');
    $results[] = checkHashString('test123', 1404181859539791111, '65.00', 'NjNiZDNiNTc5OTI2NmU2NjVmNmJjZmQ0Yjk2Y2FjMzJiY2I5MWI5');
    $results[] = checkHashString('test123', 1404211146064211111, '897.00', 'NTQzNjdmODA1ZTJhN2QyOTg1MTgxNDE1NDM3YzdiZjFiNjNlY2FlOA==');
    $results[] = checkHashString('letshashitout', 1406301520403881111, '50.00', 'MTkxOWJkMjU5YjIyODJiNTEyYTc1YTcxNzcxMmM2MTFhNGE0ZGEx==');
    echo '<pre>';
    print_r($results);
    echo '</pre>';
?>

It would be great if Click and Pledge could take a look at their algorithm. It is in fact returning less than 40 digit hashes after decoding. This means it is either a SHA error, a string building error or a base64 Encoding error on their side. I am leaning toward a encoding or string error.

is something going on with the backend? The hashes that I'm getting back are matching only occasionally.
The hashes being passed back from portal.clickandpledge.com don't always end in the == yet my calculated hashes always do.
I've made a sample donation page here: https://kellpartners-sj--developer-e...nate?test=true

and that posts to a super simple processor page. http://kellpartners.com/development/testHashCode2.php

So far the passed hash code is has been valid ~15% of the time, and since my calculated hashes always look similar, yet the CP passed hash seems to be changing in length, I can only assume there's something going on in the backend that's calculating the CP hash? Because according the the SHA1 specification it always returns the same length hash.