Similar key validation error

[antoniogeroncio]

Hello!

Sorry for my English,
I have possibly encountered an error in the library, I am running the following scenario:

I created two tokens:

secretkey1 = 6uh04S60wnp7R6YvyNXtJzHMRpvsG0MsBWMuOnFP9vhXhc3AUSu6sVglcEUV

tokenSecretkey1 = eyJhbGciOiJIUzUxMiJ9.eyJleHAiOjE1MjY2Mzk2MTV9.7vEadBgnhgCJJkoPcwuailTkNl2cmjTT5ZrbkdaQv1f4GGkLetL5SvtQC0Ronis3U7of7wUlh2kzaXvl3Cbqog

secretkey2 = 6uh04S60wnp7R6YvyNXtJzHMRpvsG0MsBWMuOnFP9vhXhc3AUSu6sVglcEUVxx

tokenSecretkey2 = eyJhbGciOiJIUzUxMiJ9.eyJleHAiOjE1MjY2Mzk2MjB9.Y_T1Pzylm6kQ9IFSB3wMsIgpS4hD9DdHDVa2ZZOyykYacrPfNh3P4fSWNuHEl13Gg8XajOr02cxZ7UkZvxIm2Q

When trying to validate the two tokens with the secret key 1 the library shows that the result is valid.

Jwts.parser().setSigningKey(secretkey1).parseClaimsJws(tokenSecretkey1) = valid

Jwts.parser().setSigningKey(secretkey1).parseClaimsJws(tokenSecretkey2) = valid

Thank you

[lhazlewood]

Hi Antonio!

This is not an error - you can't just change base64 text a little bit and assume it will render a different underlying byte array - see #211 (comment) for why.

Also, if you're using HMAC, keys longer than the algorithm block length are truncated to the algorithm block length first because keys longer than the block length don't offer any added benefit in security. In other words, you can have many keys that are different, but if the keys have the same beginning bytes up to the algorithm's block length, then all the keys will work, no matter how different they may be at the end of each key.

Here is a good answer that covers this for HMAC-SHA-256 (but the principle is the same for 384 and 512), and cites the best known research paper on HMAC security proof and key lengths:

https://crypto.stackexchange.com/a/34866/28901

specfically:

HMAC-SHA-256 is designed for 256-bit (32-byte) cryptographic resistance in mind, with no strong argument that using a key with more entropy improves the security; beyond that, there is no assurance given by the best security proof available (Mihir Bellare: New Proofs for NMAC and HMAC: Security without Collision-Resistance, with extended abstract in Crypto 2006 Proceedings. Thus if the key is full-entropy, there is no strong argument to use a key of more then 32 bytes.

This is because of how HMAC works - only the block length matters. Here's an code example of an HMAC algorithm (Bouncy Castle) - where you can see that, if the key is longer than the block length, only the first N bytes are used (where N equals the block length) - line 119:

https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/macs/HMac.java#L117-L123

This is also why it is extremely important that your key length for HMAC is at least the size of the block length, otherwise your key is padded with zero bytes, which is not random, and definitely less secure (see line 131 in HMac.java above).

Finally, here is a stack overflow answer that explains why keys MUST be a minimum length for JWTs depending on your chosen algorithm:

https://stackoverflow.com/questions/40252903/static-secret-as-byte-key-or-string/40274325#40274325

I hope that helps!