-
-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty secret is accepted by encode
#1009
Comments
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days |
If you look at the RFC specification, you can see that there is a I do agree that having no secret is very counter intuitive, but it is a valid option for a JWT. |
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days |
I guess the issue closed do not need additional work as it is seems from the last comment. |
I think it would be a good idea for
jwt.encode
to raise an exception if the secret argument is an empty string.https://vulnapi.cerberauth.com/docs/vulnerabilities/broken-authentication/jwt-blank-secret
Right now it works but produces JWT that is trivially spoofed:
Of course users should not call it with empty secret but that will usually come from some configuration file, environment variable or secret store, and it is possible to have a bug somewhere along that chain and accidentally initialize it to empty value. Having the encode call fail would be safer.
This would technically be a breaking API change and there might be intentional calls with empty secret such as in tests, but I think those would be easy to swap to another non-empty test string.
The text was updated successfully, but these errors were encountered: