Releases: jpadilla/pyjwt
v1.5.2
v1.5.1
v1.5.0
Changed
- Add support for ECDSA public keys in RFC 4253 (OpenSSH) format #244
- Renamed commandline script
jwt
tojwt-cli
to avoid issues with the script clobbering thejwt
module in some circumstances. #187 - Better error messages when using an algorithm that requires the cryptography package, but it isn't available #230
- Tokens with future 'iat' values are no longer rejected #190
- Non-numeric 'iat' values now raise InvalidIssuedAtError instead of DecodeError
- Remove rejection of future 'iat' claims #252
Fixed
- Add back 'ES512' for backward compatibility (for now) #225
- Fix incorrectly named ECDSA algorithm #219
- Fix rpm build #196
Added
- Add JWK support for HMAC and RSA keys #202
v1.4.2
Bugfix release
v1.3.0
Fixed
- ECDSA (ES256, ES384, ES512) signatures are now being properly serialized [#158][
- RSA-PSS (PS256, PS384, PS512) signatures now use the proper salt length for PSS padding. [#163]
Added
- Added a new
jwt.get_unverified_header()
to parse and return the header portion of a token prior to signature verification.
Removed
- Python 3.2 is no longer a supported platform. This version of Python is rarely used. Users affected by this should upgrade to 3.3+.
v1.2.0
Fixed
- Added back
verify_expiration=
argument tojwt.decode()
that was erroneously removed in 1.1.0.
Changed
- Refactored JWS-specific logic out of PyJWT and into PyJWS superclass. [#141]
Deprecated
verify_expiration=
argument tojwt.decode()
is now deprecated and will be removed in a future version. Use theoption=
argument instead.
v1.1.0
v1.0.1
v1.0.0
Changelog
- [CLEANUP] Removed
api.header
. #85 - [DOCS] README details how to extract public / private keys from an x509 certificate. #100
- [ENHANCEMENT] Refactor api.py functions into an object (PyJWT). #101
- [ENHANCEMENT] Support
PyCrypto
andecdsa
whencryptography
isn't available. #103 - [SECURITY] Added some fixes related to algorithm and key choice. #109
- [SECURITY] Added support for whitelist validation of the
alg
header. #110
Security
A security researcher has notified JSON Web Token library maintainers about a number of vulnerabilities allowing attackers to bypass the verification step. Read more about some of this issues here.
This release fixes the vulnerabilities reported, continue reading for details.
None algorithm
Applies if you
- rely on and do not validate the
alg
field in the token header. - implement the "none" algorithm.
Impact
Attackers can craft a malicious token containing an arbitrary payload that passes the verification step.
Exploit
Create a token with the header {"typ":"JWT","alg":"none"}
. Include any payload. Do not include a signature (i.e. the token should end with a period). Note: some implementations include some basic but insufficient checking for a missing signature -- some minor fiddling may be required to produce an exploit.
Asymmetric key of a token signed with a symmetric key
Applies if you
- rely on and do not validate the
alg
field in the token header. - implement at least one of the HMAC algorithms and at least one of the asymmetric algorithms (e.g. HS256 and RS256).
Impact
If the system is expecting a token signed with one of the asymmetric algorithms, an attacker can bypass the verification step by knowing only the public key.
Exploit
Create an HS256 token. Generate the HMAC signature using the literal bytes of the public key file (often in the PEM format). This will confuse the implementation into interpreting the public key file as an HMAC key.
This release was possible thanks to the awesome @mark-adams.