Using predictable/constant cryptographic key when creating and verifing Json Web Token.

[xubowenW]

Hi, we are a research group to help developers build secure applications. We designed a cryptographic misuse detector on Java language. We found your great public repository (i.e., lilishop) from Github, and several security issues detected by our detector are shown in the following. The specific security issues we found are as follows:
(1) Location: Package: cn.lili.common.security.token Class: SecretKeyUtil.class
Security issue: Using predictable/constant cryptographic key when creating and verifing Json Web Token.
(2) Location: Package: cn.lili.common.security.security.context Class: UserContext.class
Security issue: Using predictable/constant cryptographic key when creating and verifing Json Web Token.
(3) Location: Package: cn.lili.common.security.token Class: TokenUtil.class
Security issue: Using predictable/constant cryptographic key when creating and verifing Json Web Token.

[xubowenW]

First of all, any hardcoded(predictable/constant) cryptographic key (private key or symmetric key for signing or encryption) is not secure, it can be see CWE-321, NIST Special Publication 800-57 and other public publications.
Second, I observed that lamp-core-3.7.0, lamp-util-3.7.0 are two separate librares, in which the key you use to generate or verify the JWT signature is hardcoded, All JWTs generated by applications or web programs that use these two packages can be forged.
JWT is widely used in permission granting or identity authentication, and the integrity of the JWT is guaranteed by the signature algorithm. If the signature key is obtained by others, the attacker can arbitrarily forge the JWT to obtain the corresponding permission or log in as any user.

[chopper711]

First of all, any hardcoded(predictable/constant) cryptographic key (private key or symmetric key for signing or encryption) is not secure, it can be see CWE-321, NIST Special Publication 800-57 and other public publications. Second, I observed that lamp-core-3.7.0, lamp-util-3.7.0 are two separate librares, in which the key you use to generate or verify the JWT signature is hardcoded, All JWTs generated by applications or web programs that use these two packages can be forged. JWT is widely used in permission granting or identity authentication, and the integrity of the JWT is guaranteed by the signature algorithm. If the signature key is obtained by others, the attacker can arbitrarily forge the JWT to obtain the corresponding permission or log in as any user.

Thank you for your feedback.

In the current system, JWT is just the cached key, not a direct string for permission verification. The decrypted information is also public information, so there will be no relevant security problems. If the attacker needs to invade the current system, he needs to invade redis first.

[xubowenW]

This is only a security enhancement suggestion, because our detector only detects the implementation security of JWT. Using a hard-coded secret does not conform to the security implementation specification of JWT, which may bring security risks to your system. It is recommended that you use a more secure way to store the secret used to generate the JWT.