Muliple valid sinatures when signing JWT with HS512 and HS256

[bringfeldt]

We've just noticed that when we sign a JWT with the HS512 signature algorithm we can replace the last character and still have the token's signature verified. The pattern is that if, let's say, the signature ends with an 'A' all tokens ending with 'B' to 'O' (the following 15 characters in alphabetical order) will also pass when checkin the signature. The problem also arises when we sign the tokens with the HS256 algorithm but not when signing with HS384.

I've only been able to put some investigation into the issue but for me it seems like the Base64-encoding is a possible cause to the problem.

I have written some tests to illustrate the issue, see the attached file.
//Jonas @bringfeldt

JwtTest.zip

[lhazlewood]

For security reasons, I won't open .zip files from people I don't know personally. Can you please provide a Gist or a GitHub example project?

After Base64-decoding, how long is the key byte array?

For HS256, the key should be 64 bytes (512 bits) long. For HS384 and HS512, the key should be 128 bytes (1024 bits) long.

If a key is not long enough to match the block size of the underlying hash algorithm (SHA-256 = 512 bit block size, SHA-384 and SHA-512 = 1024 bit block size), the HMAC algorithm will pad the input key with zeros to make it the length it needs.

This means that if your keys are less than the required key length, and zeros are padded, various shorter-than-expected input keys could result in the same final key used to compute the digest. If I had to guess, I think this might be happening in this case. Please let me know if otherwise!

[lhazlewood]

P.S. while those key lengths (HS256=512 bits, HS384/HS512=1024 bits) should guarantee there are no key collisions (as I think you may be seeing) for a respective algorithm, many security experts believe that 128 or 256 bit keys are just fine (even with zero padding) because brute forcing such a key is still seen outside the capability of today's common computing infrastructure. So if your Base64-decoded key is 32 bytes or longer, I wouldn't stress too much about fiddling with the Base64 string.

[bringfeldt]

Of course, my bad. Sorry about the zip-file.

Thanks for your response! I was wondering if the size of the key or the the data that is signed could explain what happens, I was curious about have this could be and it feels assuring that you don't see any immediate security issues. I will look into it based on your suggestions and I will of course let you know if I can't figure it out.

[lhazlewood]

Sounds good - please feel free to re-open this issue if you think there is work to be done by the JJWT team.

[ashu7ank]

hi guys ,the issue mentioned, I am still facing it now, only with HS512, can anyone explain exactly why is this happening, if someone does not want this to happen what needs to be fixed, we have already tried to match the block size and increased key size till 128bytes as well for HS512. this did not work

[lhazlewood]

https://github.com/jwtk/jjwt#understanding-base64-in-security-contexts