You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 21, 2022. It is now read-only.
The RSA verify function only uses the RSA public key to verify any JWT signature using RSA, as shown in https://github.com/dgrijalva/jwt-go/blob/master/rsa.go#L61-L63. This makes it difficult for any service using jwt-go to prevent a known JWT vulnerability found 3 years ago.
As I mentioned in etcd-io/etcd#9696, RSA signatures by design are generated/created with the private key and are verified with the public key. The two major vulnerabilities described are using none instead of an actual signature algorithm, this is handled in jwt-go by requiring a special constant key of jwt.UnsafeAllowNoneSignatureType in order to verify none tokens.
The other problem is that an attacker could use the public key in conjunction with HS* algorithms.
If a server is expecting a token signed with RSA, but actually receives a token signed with HMAC, it will think the public key is actually an HMAC secret key.
@joelegasse I see. There is a vulnerability only if a JWT decoder uses the same key for all algorithms to verify the signature. Based on your description, there is no such problem for jwt-go.
I am curious what is the behavior when jwt-go is setup with RSA pub/prv key and the given JWT token is using HMAC? Does it fail authentication? What error is provided?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The RSA verify function only uses the RSA public key to verify any JWT signature using RSA, as shown in https://github.com/dgrijalva/jwt-go/blob/master/rsa.go#L61-L63. This makes it difficult for any service using jwt-go to prevent a known JWT vulnerability found 3 years ago.
As explained in https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/, this implementation is vulnerable to certain attacks that hackers can defeat JWT. To fix it, private key should be used to verify JWT tokens from client, instead of using the public key.
The text was updated successfully, but these errors were encountered: