Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

JSONWebSignatureSerializer signatures from 1.0.0 do not successfully un# 1.1.0 #127

Closed
HUSSTECH opened this issue Feb 10, 2019 · 2 comments

Comments

@HUSSTECH
Copy link

Hi, following up to the #115 issue from late last year, I've been having trouble getting to the bottom of a mismatch in behaviour between the latest versions 1.0.0 (yanked) and 1.1.0 (current) as I prepare to upgrade.

Using the JSONWebSignatureSerializer, a signed token generated in 1.0.0 with the default parameters does not validly load in 1.1.0 also with default parameters. As I understood from the pallets blog post 1.0.0 and 1.1.0 are supposed to be compatible. I took a look in the repo and saw the changes made re: fallback signers, so apart from that the only variable I could obviously see which could be mismatched was the algorithm_name...but in both 1.0.0 and 1.1.0 they are already both set to "HS512". My examples below:

in 1.0.0

from itsdangerous import JSONWebSignatureSerializer
s1 = JSONWebSignatureSerializer('a-key', salt='a-salt')
s1.dumps({1:1}).decode('utf-8')
$ > eyJhbGciOiJIUzUxMiJ9.eyIxIjoxfQ.nKcizI38sjEbao_XTh9VB2vMZPYwVpoEpAJboU7BqOL7VpR-zFPyWkBzaryxrOvUKP9J74MnNIBNSOCj4ERQDQ

in 1.1.0

from itsdangerous import JSONWebSignatureSerializer
s1 = JSONWebSignatureSerializer('a-key', salt='a-salt')
s1.loads('eyJhbGciOiJIUzUxMiJ9.eyIxIjoxfQ.nKcizI38sjEbao_XTh9VB2vMZPYwVpoEpAJboU7BqOL7VpR-zFPyWkBzaryxrOvUKP9J74MnNIBNSOCj4ERQDQ')
$ > Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/huss/.virtualenvs/itsdangerous/lib/python3.6/site-packages/itsdangerous/jws.py", line 143, in loads
    self.make_signer(salt, self.algorithm).unsign(want_bytes(s)),
  File "/home/huss/.virtualenvs/itsdangerous/lib/python3.6/site-packages/itsdangerous/signer.py", line 169, in unsign
    raise BadSignature("Signature %r does not match" % sig, payload=value)
itsdangerous.exc.BadSignature: Signature b'nKcizI38sjEbao_XTh9VB2vMZPYwVpoEpAJboU7BqOL7VpR-zFPyWkBzaryxrOvUKP9J74MnNIBNSOCj4ERQDQ' does not match

I then tried the above again and explicitly set the digest_method and algorithm_name when initing the serializers. Like so:

import hashlib
from itsdangerous import JSONWebSignatureSerializer
s1 = JSONWebSignatureSerializer('a-key', salt='a-salt', signer_kwargs={'digest_method': hashlib.sha512}, algorithm_name='HS512')

...but got the same result as above.

Could not think of what the issue could be after trying many different combinations of code and versions. It's almost as if the signer digest method is ignored in all cases when using the JSONWebSignatureSerializer. All of the other signers seemed fine when I tested them. I have forked the repo and added a couple of tests here HUSSTECH@74b9bbf. I made these tests to see if an intentional mismatch of the digest_method would raise an exception, but it did not, and everything passed through as valid.

Are there any other (known) differences I'm missing between 1.0.0 and 1.1.0 specifically for JSONWebSignatureSerializer classes?

@davidism
Copy link
Member

davidism commented Feb 10, 2019

It appears JSONWebSignatureSerizlier doesn't use the fallback signer mechanism introduced in 1.1, and it appears it has always ignored signer_kwargs, probably because the signer has certain requirements in the spec that shouldn't be changed. The problem is, while it specified values for the other Signer kwargs, it didn't specify digest_method, so that was affected during the brief time that 1.0 was available.

Note that 1.0 is no longer available. It was removed from PyPI, and it shouldn't be possible for projects to continue using it. 1.1 was designed to be compatible with 0.24, and the fallback mechanism was a best effort to support the upgrade back and forth from 0.24 to 1.0 to 1.1.

Sorry for the trouble this caused. The most direct course of action at this point is for you to implement a fallback in your project. See #120 (comment) for an example. You'd need to override get_signer in the fallback class to set the digest method to hashlib.sha512.

@HUSSTECH
Copy link
Author

Sure, I expect in practice this not to be an issue. As with many other users the signers were providing short lived tokens, and our code has retry mechanisms in place to either alert users or regenerate tokens. And given not much rumble on the issues, likely not many upgraded in the 1.0.0 window. For us however, one legacy app did land on 1.0.0!

I just wanted to understand what and why it was not signing/singing correctly, and if I'd done anything wrong. Thanks for following up. Hopefully this issue will be useful to others in the future. Happy to have this closed.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 9, 2021
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants