Toggle

navigation

PARAGON INITIATIVE

Info
About Us
Quick Answers
Technology Books
White Papers
Services
Consulting
Code Auditing
Business Intelligence
App Security
App Development
Web Development
Projects
Security
Advisories
Code Audits
Blog
Contact

News and Updates

"We care about our community, online and offline"

JWT (JSON Web Tokens) is a Bad Standard That Everyone Should

Avoid
March 14, 2017 7:18 am by Scott Arciszewski

Security Engineering

If you've already decided to implement JSON Web Tokens (JWT), whether you want JSON Web Encryption (JWE) or
JSON Web Signatures (JWS), you should question this decision. You're probably making a mistake.

Everything in this blog post was written to be accurate as of RFC 7519, RFC 7515, and RFC 7516. It's possible
that new RFCs in the future could supersede the flaws detailed within.

Why You Don't Want JSON Web Tokens

A lot of developers try to use JWT to avoid server-side storage for sessions. This is almost always a terrible
mistake and invites developers to come up with clever explanations and workarounds instead of careful
engineering.

The two linked posts explain succinctly why this is a bad move, so I won't delve further into the systems
architecture issues. There are more pressing issues at stake: The standard itself is bad and leads to
insecurity.

JSON Web Signatures Makes Forgery Trivial

Quoting RFC 7515, section 4.1.1:

The "alg" (algorithm) Header Parameter identifies the cryptographic algorithm used to secure the JWS.
The JWS Signature value is not valid if the "alg" value does not represent a supported algorithm or if
there is not a key for use with that algorithm associated with the party that digitally signed or MACed
the content. "alg" values should either be registered in the IANA "JSON Web Signature and Encryption
Algorithms" registry established by [JWA] or be a value that contains a Collision-Resistant Name. The
"alg" value is a case- sensitive ASCII string containing a StringOrURI value. This Header Parameter
MUST be present and MUST be understood and processed by implementations.

We've seen this bite JWT users before, in the from of critical vulnerabilities in most JWT libraries.

There were two ways to attack a standards-compliant JWT library to achieve trivial token forgery:

1. Send a header that specifies the "none" algorithm be used

2. Send a header that specifies the "HS256" algorithm when the application normally signs messages with an
 RSA public key.

This isn't just an implementation bug, this is the result of a failed standard that shouldn't be relied on for security.
If you adhere to the standard, you must process and "understand" the header.

JSON Web Encryption is a Foot-Gun

The encryption algorithms permitted by JWE are spelled out in RFC 7518, which comes in two sections:

Key encryption, which gives you options such as:

RSA with PKCS #1v1.5 padding
RSA with OAEP padding
ECDH
AES-GCM
Message encryption, which only allows you to choose between:
AES-CBC + HMAC
AES-GCM

Let's look at some of the key encryption choices in detail. The message encryption part is OK (assuming you have
a solid GCM implementation and adequate hardware support).

If you're not familiar with cryptography, this is somewhat like pointing a gun with 5 out of 6 loaded chambers
directly at your foot and expecting to not end up with a bullet wound. Almost all of these options have one or
more security issues.

RSA with PKCS #1v1.5 Padding

RSA with PKCS #1v1.5 padding is vulnerable to a type of chosen-ciphertext attack, called a padding oracle. We
discussed RSA attacks in detail here.

RSA with OAEP Padding

RSA with OAEP padding is probably secure. OAEP has a bogus security proof but is otherwise believed to be
secure, if RSA is secure. However, there are serious doubts to the long-term security of RSA.

Most cryptographers recommend migrating away from RSA.

ECDH
JWT only allows Elliptic Curve Diffie-Hellman (ECDH) over one of the NIST curves (Weierstrass curves, which
introduce the risk of invalid-curve attacks that attackers to steal your secret keys).

If you attempt to go off-the-standard by using elliptic curves for security, you're no longer JWT standards-
compliant.

AES-GCM
Because no list of questionable public-key encryption modes could be complete without shoehorning a shared-
key encryption mode, the JWT standard also allows you to use AES-GCM to possibly exchange an AES-GCM key.

Cryptography algorithm selections should be made by professional cryptographers, not developers. Letting
developers mix-and-match protocols and algorithms is the hallmark of error-prone cryptographic designs.

A Better Solution than JWT

A better standard would only let you choose two parameters:

Which version of the protocol to use, which defines "one true ciphersuite" for each version; what follows are
pure examples:
v1: Ed25519, X25519, XSalsa20poly1305, HMAC-SHA-512-256
v2: Ed25519, X25519, XChaCha20Poly1305, keyed BLAKE2b
v3: SPHINCS-256, SIDH, NORX64-4-1, keyed BLAKE2x
What operation to perform:
Authenticated encryption
Message authentication
Public-key authenticated encryption (for server-to-server communications only)
Public-key digital signatures (for server-to-server communications only)

The closest we have to a better standard is Fernet.

Wrap-Up
So in conclusion:

Don't use JWT for sessions, as discussed in other articles

The JWS standard is completely broken, and total RFC compliance renders your applications vulnerable
The JWE standard is a minefield that non-cryptographers shouldn't be forced to navigate

What to use instead of JWT?

As stated above, Fernet is an option for most JWT use-cases. That being said:

For secure sessions: Just use cookies over HTTPS. Cookies should only store a random identifier which is
paired with a server-side persistent storage mechanism.
For signatures: Libsodium's crypto_sign() or crypto_auth() APIs (depending on use-case).
For encryption: Libsodium's crypto_secretbox() and crypto_box() APIs (depending on use-case).

Didn't Your Team Audit a JWT Library in 2015?

Yes, we did a free audit for a JWT library in 2015, but do you know what happened since?

1. That library added a None signer, which reintroduces the risk of one of the critical authentication bypass bugs
mentioned above.
2. The None signer was made the default option.

This code hadn't been released yet. The only reason I'm bringing it up is that JWT allows insecure defaults that a
well-designed standard wouldn't.

TL;DR
The JWT standards: Not even once.

This article was updated on March 14, 2017 at 3:30 PM Eastern Time to clarify a few important points.

Permalink
Discuss on Hacker News
License: Creative Commons Attribution-ShareAlike 4.0 International CC-BY-SA 4.0 Intl

Application Security
Cryptography
Encryption
Public Key Cryptography
Secret Key Cryptography
Security
Signatures

About the Author

Scott Arciszewski

Chief Development Officer

With over 13 years of software development, application security, and system administration experience, Scott
aspires to help others attain a happier work-life balance by solving difficult problems and automating trivial tasks.
He is mostly known in the community for his open source software security research and strong progressive
positions on providing tools and frameworks that are secure by default.

About

Paragon Initiative Enterprises

offers technology consulting and web development services to businesses with attention to security above and
beyond compliance.

Our Professional Experience

Archives

1. 2017
January 2017
 February 2017
March 2017
2. 2016
January 2016
February 2016
March 2016
April 2016
May 2016
June 2016
July 2016
August 2016
September 2016
October 2016
November 2016
December 2016
3. 2015
April 2015
May 2015
June 2015
July 2015
August 2015
September 2015
October 2015
November 2015
December 2015

Blog Categories

1. Business
2. Paragon Initiative
1. Community
1. Open Source
2. Pharaoh
3. Security Advice
2. Our Products
1. Airship
2. ASGard
3. Technology
1. Cryptology
2. Databases
3. Hardware
4. Programming
5. Quality Assurance
6. Security Engineering
7. System Administration
4. Uncategorized

Tags

1. Access Controls
2. Application Security
3. Authentication
4. Authorization
5. Business
6. Central Florida
7. Cryptography
8. CSPRNG
9. Data Science
10. Encryption
11. HTTPS
12. Integrity
13. Libsodium
14. Login
15. Math
16. .NET
17. Networking
18. Node.js
19. Open Source
20. Orlando
21. OWASP
22. OWASP Top Ten
23. PHP
24. PostgreSQL
25. Public Key Cryptography
26. Python
27. Ruby
28. Secret Key Cryptography
29. Security
30. Signatures
31. SQL
32. SQL Injection
33. Statistics
34. Vulnerability
35. Web Development
36. XSS

Mailing Lists

1. Paragon Initiative Quarterly

2. Paragon Initiative Vanguard

Elsewhere

1. ParagonIE on Github
2. @ParagonIE
3. Paragonie on Facebook

Need Technology Consultants?

Will tomorrow bring costly and embarrassing data breaches? Or will it bring growth, success, and peace of mind?

Our team of technology consultants have extensive knowledge and experience with application security and
web/application development.

We specialize in cryptography and secure PHP development.

Let's Work Together Towards Success

Our Security Newsletters

Want the latest from Paragon Initiative Enterprises delivered straight to your inbox? We have two newsletters to
choose from.

The first mails quarterly and often showcases our behind-the-scenes projects.

The other is unscheduled and gives you a direct feed into the findings of our open source security research
initiatives.

Quarterly Newsletter Security Announcements

Copyright 2015 - 2017 Paragon Initiative Enterprises, LLC. All right reserved. Software security and
cryptography specialists.