Make algorithm option required to verify signature #184
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the algorithm is not provided and the one in the token's header is used instead, we might be vulnerable to the attack explained here: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ For ex: A server expecting an RSA signed token would do this: `JWT.decode(token, rsa_public)` So an attacker can potentially sign a token with HS256 using the same RSA public key (which is publicly available), and the server will think it's valid. `JWT.encode({ user: 1 }, rsa_public, 'HS256')` This doesn't seem to be exploitable right now because the current implementation of OpenSSL::HMAC.digest expects a string as the key, so if rsa_public is an OpenSSL::PKey::RSA object, JWT.decode will raise an error. But it would be better not to depend on this OpenSSL::HMAC.digest behavior
excpt
approved these changes
Feb 2, 2017
This was referenced Sep 6, 2017
jurriaan
added a commit
to jurriaan/signet
that referenced
this pull request
Sep 15, 2017
This version of ruby-jwt requires specification of the algorithm (see jwt/ruby-jwt#184) for more information.
jurriaan
added a commit
to jurriaan/google-auth-library-ruby
that referenced
this pull request
Sep 15, 2017
This version of ruby-jwt requires specification of the algorithm (see jwt/ruby-jwt#184) for more information. I've created a PR on signet to. That has to be merged before ruby-jwt 2.0 can be really used (see googleapis/signet#93). Tested locally against ruby-jwt 2.0 and 1.5.6.
jurriaan
added a commit
to jurriaan/google-auth-library-ruby
that referenced
this pull request
Sep 15, 2017
This version of ruby-jwt requires specification of the algorithm (see jwt/ruby-jwt#184) for more information. I've created a PR on signet to. That has to be merged before ruby-jwt 2.0 can be really used (see googleapis/signet#93). Tested locally against ruby-jwt 2.0 and 1.5.6.
jurriaan
added a commit
to jurriaan/google-auth-library-ruby
that referenced
this pull request
Sep 15, 2017
This version of ruby-jwt requires specification of the algorithm (see jwt/ruby-jwt#184) for more information. I've created a PR on signet to. That has to be merged before ruby-jwt 2.0 can be really used (see googleapis/signet#93). Tested locally against ruby-jwt 2.0 and 1.5.6.
jurriaan
added a commit
to jurriaan/signet
that referenced
this pull request
Sep 18, 2017
This version of ruby-jwt requires specification of the algorithm (see jwt/ruby-jwt#184) for more information.
dazuma
pushed a commit
to googleapis/signet
that referenced
this pull request
Oct 4, 2017
* Support ruby-jwt 2.0 This version of ruby-jwt requires specification of the algorithm (see jwt/ruby-jwt#184) for more information. * Use specific version of JRuby to fix CI for now
oleksandrbyk
added a commit
to oleksandrbyk/olek-google-auth-library
that referenced
this pull request
Mar 4, 2019
This version of ruby-jwt requires specification of the algorithm (see jwt/ruby-jwt#184) for more information. I've created a PR on signet to. That has to be merged before ruby-jwt 2.0 can be really used (see googleapis/signet#93). Tested locally against ruby-jwt 2.0 and 1.5.6.
nhocki
added a commit
to aha-app/omniauth-jwt
that referenced
this pull request
Mar 22, 2023
Since JWT 2.0 the signature verification checks that the algorithm passed to `encode` is the same as the `alg` value in the token. If you support multiple algorithms you can pass an `algorithms: []` option to the `JWT.decode` call. This updates the omniauth strategy to allow us passing multiple options to the `decode` call to support multiple algorithms (and not just HS256). * jwt/ruby-jwt#184
pboling
pushed a commit
to omniauth/omniauth-jwt2
that referenced
this pull request
Nov 30, 2023
Since JWT 2.0 the signature verification checks that the algorithm passed to `encode` is the same as the `alg` value in the token. If you support multiple algorithms you can pass an `algorithms: []` option to the `JWT.decode` call. This updates the omniauth strategy to allow us passing multiple options to the `decode` call to support multiple algorithms (and not just HS256). * jwt/ruby-jwt#184
pboling
pushed a commit
to omniauth/omniauth-jwt2
that referenced
this pull request
Nov 30, 2023
Since JWT 2.0 the signature verification checks that the algorithm passed to `encode` is the same as the `alg` value in the token. If you support multiple algorithms you can pass an `algorithms: []` option to the `JWT.decode` call. This updates the omniauth strategy to allow us passing multiple options to the `decode` call to support multiple algorithms (and not just HS256). * jwt/ruby-jwt#184
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Looks like this was discussed before in #107, which was closed with a README update specifying the algorithm was required, but it doesn't seem like the code is actually requiring it.
If the algorithm is not provided and the one in the token's header is used
instead, we might be vulnerable to the attack explained here:
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
For ex:
A server expecting an RSA signed token would do this:
JWT.decode(token, rsa_public)So an attacker can potentially sign a token with HS256 using the same RSA public
key (which is publicly available), and the server will think it's valid.
JWT.encode({ user: 1 }, rsa_public, 'HS256')This doesn't seem to be exploitable right now because the current implementation
of OpenSSL::HMAC.digest expects a string as the key, so if rsa_public is an
OpenSSL::PKey::RSA object, JWT.decode will raise an error. But it would be
better not to depend on this OpenSSL::HMAC.digest behavior