0

I'm implementing an online payment system : Paybox.

I've got an autoresponse (between servers) and a response (attached to my customer when he is returning to my website.

Everything's good except for the signature which is a SHA1. On the autoresponse side I have a valid sign:

ahkjqBWxsi2rMXWpQr9LaQFelTIGJ93pKfGt2E6lT1sIKABsNanexC0gZvt5Z8ShgQXUsGBS10QVPzUxmYDhWpuDKIiHDZ5i9mLm2UGz8LOJeGkIlikuXOCC3ny

However, with the customer (me for this test), I have:

ah8R%2F2mvvpc8Jo016XyO7WZbqmQktb%2BShME6A0X3hwCNWkkGXb1YI9wIS7RSCK1IJKotbYni8BxBNoHTKcLxdA9nOQPcQSD%2FUM3%2BdiptrnTuLZ1jP9bIDCvDtSav7WG509gw5PbEztpl5lOZlnIFuCMzC3Ps%2B2Rt%2FO6PSZfHgvA%3D

I don't understand :

1) Why are they différent.

2) Why does the second have '%' characters which can not be output from a SHA1

I thought about a different encoding but nothing so far, any idea?

Thanks

Alex K.
  • 171,639
  • 30
  • 264
  • 288
Faquarl
  • 158
  • 1
  • 9

1 Answers1

0

%2F and %2B are URL encoded characters; / and + respectively.

You likely see them because they can appear in a Base64 encoded string and thats what you appear to have (despite their absence in the 1st example) given that you cannot represent a raw SHA1 hash as a string.

In many scenarios you cannot use HTTP to send a string containing those characters in their raw form as they have special meaning, see Passing base64 encoded strings in URL.

Assuming functioning encoding/decoding and SHA1 code then the reason the two hashes are different is because the input data was different.

Community
  • 1
  • 1
Alex K.
  • 171,639
  • 30
  • 264
  • 288
  • The problem is that these 2 strings should be the same, the method they are encoded with and the data used for encoding is the same according to the documentation... – Faquarl Apr 20 '16 at 15:07