Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful(insomniasec.com)
insomniasec.com
Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful
https://insomniasec.com/blog/auth0-jwt-validation-bypass
96 comments
Before starting a new project some time ago, I read about the critics to JOSE (JWE) and the alternative PASETO. I decided to use JOSE carefully instead of PASETO because it had an IETF RFC. I think it will be great for PASETO to get a RFC as well. The second point that made me chose JOSE was that PASETO was a bit too mean towards JOSE, and I didn't want drama in my technology choices.
But good work! With a RFC PASETO will be my choice for my next projects.
But good work! With a RFC PASETO will be my choice for my next projects.
We use it, but restrict the sig alg to a couple of known-good values, so am hoping this particular vulnerability is not present in our system.
We had an infosec guy excitedly tell us that PASETO was the future, and we need to change to it right now. It looked good, and a way to avoid some of the possible JiWY issues in the same way having a TLS implementation that only allowed strong ciphers might.
But we have to integrate with so many third party pieces that require JWT it wasn't an option.
We had an infosec guy excitedly tell us that PASETO was the future, and we need to change to it right now. It looked good, and a way to avoid some of the possible JiWY issues in the same way having a TLS implementation that only allowed strong ciphers might.
But we have to integrate with so many third party pieces that require JWT it wasn't an option.
Why a new standard than to push for reform to the current standard?
Are they just closely protected by greybeards who won't listen to reason?
Question comes from a true place of ignorance/curiosity, I definitely understand the need to have unambiguous, easy to implement security tokens without the foot-guns.
Are they just closely protected by greybeards who won't listen to reason?
Question comes from a true place of ignorance/curiosity, I definitely understand the need to have unambiguous, easy to implement security tokens without the foot-guns.
Simple answer: Because secure cryptography is backwards-incompatible with insecure cryptography, and the JOSE standards have a lot of legacy cruft that will be hard to jettison.
If you're going to put in the work (which I am), you might as well start with a clean slate rather than trying to piecemeal security improvements into their design-by-committee spec.
If you're going to put in the work (which I am), you might as well start with a clean slate rather than trying to piecemeal security improvements into their design-by-committee spec.
Thank you for your reply!
Speaking as a recidivist greybeard, not sure why you'd think we'd have anything to do with something as callow and unproven as Javascript.
JWT has nothing to do with javascript, other than being one of the many many languages that have JWT implementations.
It has a huge vibe of incompetent reinwheeling that is natural to the javascript ecosystem because of the web explosion that gave us a large amount of people with no clue.
Just because you have a poisoned view of javascript doesn't mean that everything bad has something to do with javascript. In this case JWT was designed by a C# developer at Microsoft. Maybe you can shift gears to whining about .NET in every thread now?
Oh hey look, he standardised POSIX threads. maybe everything bad is from POSIX?
https://www.microsoft.com/en-us/research/people/mbj/
Oh hey look, he standardised POSIX threads. maybe everything bad is from POSIX?
https://www.microsoft.com/en-us/research/people/mbj/
"You have a poisoned view"? That's just your opinion. I tried to base mine on a somewhat objective observation about speeds and volumes of stuff happening.
"Everything bad has something to do with javascript"? Don't put words in my mouth.
"A C# developer at Microsoft" plus a javascript explosion. Aren't you just confirming my point? Those new people didn't materialise out of thin air, they may have been software developers who had to change focus rapidly. And they didn't necessarily knew how their creations could be misused under the rules of that new javascript world.
And he doesn't look old enough to be a designer of POSIX threads.
(if you don't like my expression about the "vibe" then I'll give you an example of a protocol with a C vibe: the type value would be a fixed-length field with a table of integer IDs written in the standard; everyone would complain about integer sign, wrap-arounds and the new extension field that was added because we ran out of IDs)
"Everything bad has something to do with javascript"? Don't put words in my mouth.
"A C# developer at Microsoft" plus a javascript explosion. Aren't you just confirming my point? Those new people didn't materialise out of thin air, they may have been software developers who had to change focus rapidly. And they didn't necessarily knew how their creations could be misused under the rules of that new javascript world.
And he doesn't look old enough to be a designer of POSIX threads.
(if you don't like my expression about the "vibe" then I'll give you an example of a protocol with a C vibe: the type value would be a fixed-length field with a table of integer IDs written in the standard; everyone would complain about integer sign, wrap-arounds and the new extension field that was added because we ran out of IDs)
This is conspiracy theory logic. You could literally use this same line of argument to blame anything bad on a vague "explosion of javascript", fact free. Not very impressive either since it relies on smearing people's competence and professionalism based on handwaving instead of any kind of serious engagement with the facts of the situation. Moving on.
Numbers of developers and code aren't vague. They are disproportionately significant. And you don't even use arguments, just a low-effort labeling.
> Why a new standard than to push for reform to the current standard?
Or even just an opinionated library with some basic guardrails to prevent bad configurations.
Or even just an opinionated library with some basic guardrails to prevent bad configurations.
That's tempting, but as long as a standard has design flaws, there will be libraries out there that don't prevent bad configurations, and people (through innocent ignorance) will use them and end up in a bad place.
The whole point of modern cryptography is to take all the oodles of rope to hang yourself with and hand it over to the cryptographers, to leave just the absolute minimum amount of rope with the application developers.
JWT is the opposite of that. It's essentially a reenactment of the bad parts of 90s crypto, including RSA and NONE ciphers.
JWT is the opposite of that. It's essentially a reenactment of the bad parts of 90s crypto, including RSA and NONE ciphers.
I mean, "basic guardrails" is basically exactly what Auth0 tried to do here with their algorithm check, and see how that turned out.
I think we're going to use PASETO for some stuff at WorkOS. Thanks for building it. :)
(googler, opinions are my own)
For server-to-server, I continue to prefer PGP to provide my encryption. While Google Payments[0] supports PGP and JWE for encrypting payloads, PGP is well tested and most of the bugs have been worked out. JWS/JWE continues to have implementation bugs (likely due to being too flexible).
[0] https://developers.google.com/standard-payments/reference/be...
For server-to-server, I continue to prefer PGP to provide my encryption. While Google Payments[0] supports PGP and JWE for encrypting payloads, PGP is well tested and most of the bugs have been worked out. JWS/JWE continues to have implementation bugs (likely due to being too flexible).
[0] https://developers.google.com/standard-payments/reference/be...
PGP isn't great either: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
Better options for PGP use cases:
- AWS Encryption SDK: https://docs.aws.amazon.com/encryption-sdk/latest/developer-...
- age https://age-encryption.org
- Magic Wormhole https://github.com/warner/magic-wormhole
- NaCl/libsodium (and/or usability wrappers) https://libsodium.gitbook.io/doc/
Better options for JWE use cases:
- PASETO: https://paseto.io
- Branca: https://branca.io
Better options for PGP use cases:
- AWS Encryption SDK: https://docs.aws.amazon.com/encryption-sdk/latest/developer-...
- age https://age-encryption.org
- Magic Wormhole https://github.com/warner/magic-wormhole
- NaCl/libsodium (and/or usability wrappers) https://libsodium.gitbook.io/doc/
Better options for JWE use cases:
- PASETO: https://paseto.io
- Branca: https://branca.io
What are the main differences between Branca and PASETO?
Based on my brief reading of both, it seems like the main differences are:
* Branca has no signing mode, just authenticated encryption (eg. only "local" mode)
* Branca's payload is just arbitrary bytes, whereas PASETO has a defined payload format
* Seems like the same ciphers are used for Branca and PASETO v2/local.
Is that a fair assessment?
Based on my brief reading of both, it seems like the main differences are:
* Branca has no signing mode, just authenticated encryption (eg. only "local" mode)
* Branca's payload is just arbitrary bytes, whereas PASETO has a defined payload format
* Seems like the same ciphers are used for Branca and PASETO v2/local.
Is that a fair assessment?
Yep, that's a fair assessment.
If you want ultra-simplicity and don't need clearsigned tokens (i.e. signed by a third party), you can get away with just using Branca. PASETO covers both use cases.
If you want ultra-simplicity and don't need clearsigned tokens (i.e. signed by a third party), you can get away with just using Branca. PASETO covers both use cases.
Hm, I think I prefer branca from a quick look (simpler is better). I'm a little worried that both seem to hide away datestamp/validity though.
Branca notes checking the timestamp as optional - I couldn't tell what paseto does by default - other than a reference to a timestamp in the implentor's readme (and then only as an example parameter to the php code).
Paseto does helpfully state that there's no replay protection - so don't use it for stateless (serveless) session tokens.
But to both/either default to some kind of timeout?
I don't really see any use cases where I'd want infinite validity - so in addition to sane algorithms, sane/required exipery seems like it should be part of such things?
I think I might want a serial and a black-list too.. But maybe there are cases where invalidation aren't ever needed? I can't think of one right now.
Branca notes checking the timestamp as optional - I couldn't tell what paseto does by default - other than a reference to a timestamp in the implentor's readme (and then only as an example parameter to the php code).
Paseto does helpfully state that there's no replay protection - so don't use it for stateless (serveless) session tokens.
But to both/either default to some kind of timeout?
I don't really see any use cases where I'd want infinite validity - so in addition to sane algorithms, sane/required exipery seems like it should be part of such things?
I think I might want a serial and a black-list too.. But maybe there are cases where invalidation aren't ever needed? I can't think of one right now.
PASETO has the same "claims" as JWT, except they're ISO 8601 timestamps rather than integers (UNIX timestamps).
They're not required (as they weren't in JWT). If you want to use them, use them. The parser will validate them if you want it to.
https://github.com/paragonie/paseto/blob/master/src/Rules/No...
https://github.com/paragonie/paseto/tree/master/docs/02-PHP-...
They're not required (as they weren't in JWT). If you want to use them, use them. The parser will validate them if you want it to.
https://github.com/paragonie/paseto/blob/master/src/Rules/No...
https://github.com/paragonie/paseto/tree/master/docs/02-PHP-...
Thanks for the pointers - I'd looked at that, I think, but missed the add-rule bit.
But to be clear, it's easy to set up the validating service so that it accepts a token with expired timestamp as valid - it's the default to not check the timestamp if present?
A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?
But to be clear, it's easy to set up the validating service so that it accepts a token with expired timestamp as valid - it's the default to not check the timestamp if present?
A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?
The default is to not enforce any rules beyond the cryptographic signatures.
If you need any other validations, it's entirely up to you to specify what those are.
You might care about checking `exp`, but I might instead care about `iat` with a hard-coded token lifetime.
PASETO supports whatever zany business logic developers need, but doesn't enforce anything by default.
But once you add a rule to your parser, it will fail-closed on those rules.
> A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?
Correct.
If your parser is set to check timestamps and one is invalid or omitted, it throws an exception.
If you need any other validations, it's entirely up to you to specify what those are.
You might care about checking `exp`, but I might instead care about `iat` with a hard-coded token lifetime.
PASETO supports whatever zany business logic developers need, but doesn't enforce anything by default.
But once you add a rule to your parser, it will fail-closed on those rules.
> A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?
Correct.
If your parser is set to check timestamps and one is invalid or omitted, it throws an exception.
OK. I think a brief paragraph along these lines probably should be in (one of) the readme(s).
Personally I think temporal validity really is needed in most cases - and probably should be default. I suppose maybe not for use as long lived api-keys. Then again... infinent validity is almost certainly wrong..
From time to time I wonder how I'd implement kerberos for the web today - probably trading shared secrets for public key/anchoring trust in certificates... And I usually end up realizing it likely will end up just as complex as kerberos5, with similar trade-off/weaknesses (eg ticket hijack).
Maybe paseto has different goals (which is fine) - and maybe it makes sense as a building block - but I think I'd like to see a simple toke spec that demands: valid keys/certs, blacklist/revocation, temporal validity (the simplest is probably a valid from/to on the token). And no crypto algo agility/negotiation etc.
What is the prime motivation behind/use case/goal for paseto?
Personally I think temporal validity really is needed in most cases - and probably should be default. I suppose maybe not for use as long lived api-keys. Then again... infinent validity is almost certainly wrong..
From time to time I wonder how I'd implement kerberos for the web today - probably trading shared secrets for public key/anchoring trust in certificates... And I usually end up realizing it likely will end up just as complex as kerberos5, with similar trade-off/weaknesses (eg ticket hijack).
Maybe paseto has different goals (which is fine) - and maybe it makes sense as a building block - but I think I'd like to see a simple toke spec that demands: valid keys/certs, blacklist/revocation, temporal validity (the simplest is probably a valid from/to on the token). And no crypto algo agility/negotiation etc.
What is the prime motivation behind/use case/goal for paseto?
PGP definitely has it's issues. It is a good tool for dealing with files, but yeah, it has it's problems.
It looks like Google's security team prefers the use of Tink[0] when having to encrypt things.
[0] https://github.com/google/tink
It looks like Google's security team prefers the use of Tink[0] when having to encrypt things.
[0] https://github.com/google/tink
Tink is great! I wish there were more supported languages.
AEAD and AWS KMS to decrypt the key set is perfect for our needs.
Yes, Tink is acceptable too. :)
Tink is fantastic.
To come back to one other point. Why Google payments uses PGP: because all other payment companies in the world do too. We work with many different companies, and when dealing with files, they all figured out how to use PGP 20+ years ago and probably won't change unless they are forced to. :)
(googler opinions are my own)
(googler opinions are my own)
> PGP is well tested and most of the bugs have been worked out.
Most of them.
You're either using gnupg or you're using some custom PGP implementation.
A custom PGP implementation has far more footguns than a restricted JWT implementation.
Gnupg is a deeply terrifying codebase- for example, did you know you're not supposed to use the exit code of gpg --verify? You must parse statusfd, too, or many bugs will let you spoof signatures. (Bugs found as recently as this year).
I'd encourage anybody considering using gnupg for anything to read mainproc.c and see if they understand what's going on.
Most of them.
You're either using gnupg or you're using some custom PGP implementation.
A custom PGP implementation has far more footguns than a restricted JWT implementation.
Gnupg is a deeply terrifying codebase- for example, did you know you're not supposed to use the exit code of gpg --verify? You must parse statusfd, too, or many bugs will let you spoof signatures. (Bugs found as recently as this year).
I'd encourage anybody considering using gnupg for anything to read mainproc.c and see if they understand what's going on.
And to be clear, these are not "oh, an adaptive chosen plaintext attack and 2^56 compute may be able to forge signatures" bugs.
These are real, exploitable, and many of the fixes probably won't be backported.
These are real, exploitable, and many of the fixes probably won't be backported.
> I'm pushing for an IETF RFC this year.
Are you planning an informational document, or going through the IETF standardization process?
Also, the last published draft is two years old this week. Have there been changes since then to the spec? Are implementations generally interoperable?
Are you planning an informational document, or going through the IETF standardization process?
Also, the last published draft is two years old this week. Have there been changes since then to the spec? Are implementations generally interoperable?
I'll be sending an email to CFRG, probably next week, with any spec changes.
But before I resuscitate PASETO, XChaCha20 needs an RFC. It's pending IRTF kick-off.
https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03
But before I resuscitate PASETO, XChaCha20 needs an RFC. It's pending IRTF kick-off.
https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03
I'm going to use PASETO for a personal project I'm working on. If the COVID lockdown ever ends and I have time to work on it. Thanks for building it!
Paseto is a great project, thank you very much for your contribution!
What IETF WG are you working through?
CFRG
Are there links to more recent discussions on CFRG? Did you take any of the critiques from CFRG to heart? I think the v1/v2 local/public points were well-taken.
Nothing from 2020 yet. XChaCha has to be prioritized first.
Good luck! Seems like previous discussions with the mailing list could have gone better, but PASETO seems like promising work!
Hi all - Shiv from Auth0. I am the CPO and wanted to share some additional context here. On July 31st 2019, at 5:11 am, we received an email from Insomnia reporting a service vulnerability. By 11:00 pm the same day, we had fixed the issue in production. We analyzed the logs and validated that no one exploited the vulnerability. More details from our CSO here: https://auth0.com/blog/insomnia-security-disclosure/?utm_sou.... Thanks to Insomnia for reporting the vulnerability and their partnership in coordinated disclosure. We appreciate the continued feedback from the security community-at-large to ensure we are providing the most secure platform for our global customers.
Why did your implementation have a case-sensitive check for a fixed list of algorithms, and why are you blacklisting vs. whitelisting acceptable algorithms? 'Old, stable' codebase or not... this is production code for a security product and seems like something that would be picked up during an audit.
Not the OP but, the sad truth is that code audits aren't that good at eradicating bugs.
I've encountered issues like this in various systems using JWT at this point. The real problem is that developers blacklist the algorithms they don't want. Instead, the verification code should explicitly whitelist which algorithms you support.
More specifically, you can't even rely on using the 'alg' parameter before successful signature verification with any level of authority: after all, it is protected by the signature it declares the algorithm for itself. So even with a whitelist, there is the potential of downgrade attacks.
In other words, don't even use a whitelist, use a single specific expected algorithm.
More specifically, you can't even rely on using the 'alg' parameter before successful signature verification with any level of authority: after all, it is protected by the signature it declares the algorithm for itself. So even with a whitelist, there is the potential of downgrade attacks.
In other words, don't even use a whitelist, use a single specific expected algorithm.
I have a coworker who does shit like this all the time.
The list of supported options is not only knowable, but changes very slowly. Which means it's almost certainly known at commit time. Just enumerate them. By hand. Oh no, you might have to type in some text that exists somewhere else! Quelle horreur!
The list of unsupported options is unknowable. The list of string or path interpolation bugs is knowable, but isn't known by the sort of person who thinks a whitelist is a bad idea. Build a lookup table and stop trying to be clever.
The list of supported options is not only knowable, but changes very slowly. Which means it's almost certainly known at commit time. Just enumerate them. By hand. Oh no, you might have to type in some text that exists somewhere else! Quelle horreur!
The list of unsupported options is unknowable. The list of string or path interpolation bugs is knowable, but isn't known by the sort of person who thinks a whitelist is a bad idea. Build a lookup table and stop trying to be clever.
fn verify_jwt(
// The input from the network/user; the JWT we will be verifying
untrusted_jwt: String,
// *The* way in which we expect JWTs to be issued / we will be verifying against:
verifier: Verifier,
) -> ... {
// Basic sanity checks & decoding.
let untrusted_jwt: Jwt = ...;
if !verifier.acceptable_alg(untrusted_jwt.alg) {
bail;
}
verifier.verify(untrusted_jwt)
}
I'm largely omitting¹ JWE, so perhaps there's some hidden dragon in there, or perhaps we just handle those completely separately. But for JWS, am I missing something? Unless you pass `NoneVerifier`, in which case you're explicitly opting in to alg: none and it's goriness.
Sadly, I don't think any of the top three Rust libraries do this.
¹I'm also omitting that RSA has many attached hash algorithms in JWS; one can imagine that JwtRsa might let you configure what hashers it will/will not use. As it is, some libraries take sort of this form, but split the key material off from the algorithm … letting you pass craziness like an RSA key material and HMAC-SHA256, which makes no sense. That is, what hash algorithms (if any) are possible is a function of the type of key material coming in.
¹I'm also omitting verification of the claims, which I think a library should generally handle.
Is there some good reason to prefer a blacklist in this case, that I'm not thinking of, that might change my reaction to this from "uh, maybe I need to entirely re-think my assumption that Auth0 is any better at this whole securing-users thing than I am"? My immediate and ongoing reaction to the headline was and is, "wait, a blacklist? WTF!"
The purpose of a blacklist is to seamlessly support newer algorithms invented later.
For example consider SHA1 replaced by SHA256 by SHA512. If some components is hardcoded to only accept SHA1, it can't use the newer algorithms and potentially block adoption by other components.
So it's somewhat normal design for future proofing, but it's a bit stupid for security/authentication stuff which sole purpose is to verify messages.
For example consider SHA1 replaced by SHA256 by SHA512. If some components is hardcoded to only accept SHA1, it can't use the newer algorithms and potentially block adoption by other components.
So it's somewhat normal design for future proofing, but it's a bit stupid for security/authentication stuff which sole purpose is to verify messages.
I get why you'd use a blacklist in general, but it seems obvious to me that in a case like this you do not want to allow any algo you haven't cleared first. Especially since it may not be better! What if your underlying library decides it's gonna support md5 hashes for signatures?
What system of application deployment and maintenance are you picturing where a new crypto algorithm shows up on a machine without an opportunity to make a one-line commit to your codebase?
And in a SaaS setting, what operational environment is going to want you to start using a new cryptographic algorithm with no formalism around the process? Someone is going to want to flip a proverbial switch.
And in a SaaS setting, what operational environment is going to want you to start using a new cryptographic algorithm with no formalism around the process? Someone is going to want to flip a proverbial switch.
Look no further than OpenSSL and Windows SSL.
These libraries doing the crypto, often managed by the OS, are upgrading the TLS protocol and ciphers on the fly with most applications having no awareness of what's going on.
These libraries doing the crypto, often managed by the OS, are upgrading the TLS protocol and ciphers on the fly with most applications having no awareness of what's going on.
I would argue the opposite. openSSL is such a can of worms at this point that if you suggested this sort of magic thinking in a design meeting, you'd have a fight on your hands and I wouldn't be the only person arguing with you.
> Instead, the verification code should explicitly whitelist which algorithms you support.
What libraries are you using? I just looked through the auth code for a project I'm working on (which uses `jsonwebtoken`) and it has an option to whitelist algorithms in the `jwt.verify` method.
Edit: removed repeated info
What libraries are you using? I just looked through the auth code for a project I'm working on (which uses `jsonwebtoken`) and it has an option to whitelist algorithms in the `jwt.verify` method.
Edit: removed repeated info
Various, been a while since I wrote code using them myself.
Often JWT tokens come from sources other than our own and they will have passed through user agent or client land. Don't trust anything in them unless you verified them.
edit: good on that library! That's what it should do. Clearly auth0's code did not do that though, it should never have accepted any variant of 'none' in the first place.
Often JWT tokens come from sources other than our own and they will have passed through user agent or client land. Don't trust anything in them unless you verified them.
edit: good on that library! That's what it should do. Clearly auth0's code did not do that though, it should never have accepted any variant of 'none' in the first place.
Just wanted to point out the supreme irony: Auth0 wrote that library.
Hah. They could still improve it by only accepting a single algorithm, rather than a list.
edit: though there could be some internal use cases where you want a list, but it's a tradeoff between flexibility and making it easy for people to shoot themselves in the foot.
edit: though there could be some internal use cases where you want a list, but it's a tradeoff between flexibility and making it easy for people to shoot themselves in the foot.
If you don't set it it's set to a reasonable list of algorithms [0], which doesn't include "none"
https://github.com/auth0/node-jsonwebtoken/blob/master/verif...
https://github.com/auth0/node-jsonwebtoken/blob/master/verif...
Does it also have the option to blacklist algorithms? Because if so, people are going to use that option.
It's fascinating how Auth0 actually had a blog post about finding and fixing a handful of JWT vulnerabilities years ago (one of them is more advanced to exploit than this). Just another example of why you always have to be vigilant and that properly implementing encryption/security is hard
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
At some point, that alg parameter gets resolved to an algorithm - an object or enum constant or something. This bug implies that the filtering was done on the string value of the parameter, and not the resolved value. That seems like a schoolboy error.
It's much worse than that. There are like 5 options for the algorithm value, none, RS256, HS256, etc...
The vulnerabilities implies that they don't verify the value against the very limited list of possible values, which is incredibly stupid.
The vulnerabilities implies that they don't verify the value against the very limited list of possible values, which is incredibly stupid.
The gist of this Auth0 authentication API bypass is detailed as follows:
> The Authentication API prevented the use of alg: none with a case sensitive filter. This means that simply capitalising any letter e.g. alg: nonE, allowed tokens to be forged.
I really don't know what to think of why you need a case-sensitive filter for alg:'none'. The question is that why use and support 'alg:none' in the standard in the first place? As I previously commented, the option to have 'alg: none' should never be used as it is still the biggest footgun in the JOSE specification. Even giving the user a choice of ciphers to use is a recipe for disaster. Thus, JWT is still a cryptographically weak standard and its use is discouraged by many cryptographers.
PASETO [0] or Branca [1] are cryptographically stronger alternatives to use over JWT here.
[0] https://paseto.io
[1] https://branca.io
> The Authentication API prevented the use of alg: none with a case sensitive filter. This means that simply capitalising any letter e.g. alg: nonE, allowed tokens to be forged.
I really don't know what to think of why you need a case-sensitive filter for alg:'none'. The question is that why use and support 'alg:none' in the standard in the first place? As I previously commented, the option to have 'alg: none' should never be used as it is still the biggest footgun in the JOSE specification. Even giving the user a choice of ciphers to use is a recipe for disaster. Thus, JWT is still a cryptographically weak standard and its use is discouraged by many cryptographers.
PASETO [0] or Branca [1] are cryptographically stronger alternatives to use over JWT here.
[0] https://paseto.io
[1] https://branca.io
> the option to have 'alg: none' should never be used
I doubt anyone uses this deliberately (edit: except maybe for internal server to server communications?). I agree that having it as an option is a footgun. I still think this is a non-issue on the client/backend, most libraries explicitly make you whitelist token signing algorithms and will throw errors if the token isn't signed with the right algorithm.
> Even giving the user a choice of ciphers to use is a recipe for disaster.
How so? I'm still learning this stuff, so I'm genuinely curious.
I doubt anyone uses this deliberately (edit: except maybe for internal server to server communications?). I agree that having it as an option is a footgun. I still think this is a non-issue on the client/backend, most libraries explicitly make you whitelist token signing algorithms and will throw errors if the token isn't signed with the right algorithm.
> Even giving the user a choice of ciphers to use is a recipe for disaster.
How so? I'm still learning this stuff, so I'm genuinely curious.
> How so? I'm still learning this stuff, so I'm genuinely curious.
It is the same reason why the author of Wireguard rejected cryptographic agility in its use of protocols and ciphers:
From the Wireguard paper [0]:
> 'Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.'
[0] https://www.wireguard.com/papers/wireguard.pdf
It is the same reason why the author of Wireguard rejected cryptographic agility in its use of protocols and ciphers:
From the Wireguard paper [0]:
> 'Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.'
[0] https://www.wireguard.com/papers/wireguard.pdf
> > Even giving the user a choice of ciphers to use is a recipe for disaster.
> How so? I'm still learning this stuff, so I'm genuinely curious.
https://paragonie.com/blog/2019/10/against-agility-in-crypto... :)
> How so? I'm still learning this stuff, so I'm genuinely curious.
https://paragonie.com/blog/2019/10/against-agility-in-crypto... :)
I really hope you're planning some agility in PASETO otherwise it's de-facto s* protocol that will have to be thrown away within a few years upon the first cryptographic weakness, breaking all applications that dared to adopt it.
Fact is, ciphers and protocols evolve over time. In the real world of client-servers (often many clients and many servers), it's not possible to magically upgrade all systems at once to exclusively accept a single same cipher. There's got to be a way to phase-in ciphers gradually across systems and phase-off. Agility is simply a real world constraint to be able to operate software in the real world.
Fact is, ciphers and protocols evolve over time. In the real world of client-servers (often many clients and many servers), it's not possible to magically upgrade all systems at once to exclusively accept a single same cipher. There's got to be a way to phase-in ciphers gradually across systems and phase-off. Agility is simply a real world constraint to be able to operate software in the real world.
> I really hope you're planning some agility in PASETO otherwise it's de-facto s* protocol that will have to be thrown away within a few years upon the first cryptographic weakness, breaking all applications that dared to adopt it.
Instead of cipher agility, PASETO uses versioned protocols.
My DEFCON Crypto & Privacy Village talk (slides and YouTube video at https://paseto.io for the curious) covered this distinction in detail.
Instead of cipher agility, PASETO uses versioned protocols.
My DEFCON Crypto & Privacy Village talk (slides and YouTube video at https://paseto.io for the curious) covered this distinction in detail.
It’s versioned, which is an improvement on “agility”
Protocols agility allow applications to pick between multiple settings, let's say RSA128 and RSA256 for example. This allows to add and remove ciphers over time, which is very important.
In theory it's a bad idea, because it means stuff might select obsolete ciphers during operation, which is bad.
In practice, there is no choice but to design agility. Ciphers will invariably get weak after some years (computer get faster) so they need to be phased off and replaced by newer ones.
In the real world, there are meshes of client-server interacting with one another. You can't just upgrade the software on one side to only use the newer cipher, or nothing could connect to it anymore. Thus there has to be the capability to work with multiple ciphers, so older ciphers can gradually be phased-in across systems and older cipher phased-off.
Pretty sure the two other commenters are mostly researchers with no real world software deployment to manage. Otherwise they wouldn't be so strong against agility. Fact is a system with no agility is dead in the water because it can't evolve.
In theory it's a bad idea, because it means stuff might select obsolete ciphers during operation, which is bad.
In practice, there is no choice but to design agility. Ciphers will invariably get weak after some years (computer get faster) so they need to be phased off and replaced by newer ones.
In the real world, there are meshes of client-server interacting with one another. You can't just upgrade the software on one side to only use the newer cipher, or nothing could connect to it anymore. Thus there has to be the capability to work with multiple ciphers, so older ciphers can gradually be phased-in across systems and older cipher phased-off.
Pretty sure the two other commenters are mostly researchers with no real world software deployment to manage. Otherwise they wouldn't be so strong against agility. Fact is a system with no agility is dead in the water because it can't evolve.
This is exactly backwards.
In theory cipher agility is useful so you can upgrade your suite over time, in practice it’s a terrible idea because it will, and has time and again, lead to downgrade attacks.
Crypto researchers have learned this fact of life the hard way, crypto systems are becoming less “agile” over time because this agility means it’s preemptively broken.
In theory cipher agility is useful so you can upgrade your suite over time, in practice it’s a terrible idea because it will, and has time and again, lead to downgrade attacks.
Crypto researchers have learned this fact of life the hard way, crypto systems are becoming less “agile” over time because this agility means it’s preemptively broken.
> The question is that why use and support 'alg:none' in the standard in the first place?
FTFA:
> The JWT standard supports insecure JWT algorithms for scenarios where encryption and a signature are not suitable, such as trusted server-to-server communication. In these scenarios, the none algorithm is specified in the JWT header. The none alg type should never be used for untrusted user-supplied tokens.
FTFA:
> The JWT standard supports insecure JWT algorithms for scenarios where encryption and a signature are not suitable, such as trusted server-to-server communication. In these scenarios, the none algorithm is specified in the JWT header. The none alg type should never be used for untrusted user-supplied tokens.
It's funny that they say it's "not suitable" when it's really just pure laziness. It takes two seconds to create a secret key and use the HS256 algorithm to generate and verify a signature.
Creating a key is easy; storing it securely and giving access to only the parts of your system that need it takes a bit more work.
Of course, if you trust your network and the parties involved well enough that you'd be fine with unencrypted and unauthenticated data, I guess it doesn't matter if you just check the key into a git repo somewhere... but then you're potentially normalizing bad practices, even if in that particular instance it might be ok.
Of course, if you trust your network and the parties involved well enough that you'd be fine with unencrypted and unauthenticated data, I guess it doesn't matter if you just check the key into a git repo somewhere... but then you're potentially normalizing bad practices, even if in that particular instance it might be ok.
"trusted server"
Most JWT libraries require to hardcode the expected algorithm when verifying a token, so if your applications are verifying the token provided by Auth0 with a JWT library, they're most likely not vulnerable to this mistake.
I think what's more harmful is the fact that something is case-insensitive.
Case insensitive may have some benefits for human-facing stuff, but otherwise the byte-exact comparison you get with case-sensitive semantics is superior.
Case insensitive may have some benefits for human-facing stuff, but otherwise the byte-exact comparison you get with case-sensitive semantics is superior.
There's actually three lessons to be drawn from this incident:
1. Don't use JWT, it's too easy to mess up.
2. If you're trying to fence off some sort of format or API, whitelist things, don't blacklist them.
3. This narrative that "you should use a third-party authentication provider because they're security experts and are much less likely to get it wrong"... well... I think you can see where I'm going with this.
1. Don't use JWT, it's too easy to mess up.
2. If you're trying to fence off some sort of format or API, whitelist things, don't blacklist them.
3. This narrative that "you should use a third-party authentication provider because they're security experts and are much less likely to get it wrong"... well... I think you can see where I'm going with this.
What if someone used the correct case but weird Unicode characters? I mean, if "none" = "nonE", is "none" = "ｎｏｎｅ"
https://github.com/auth0/node-jsonwebtoken/blob/5f10bf9957a2...
The end result depends entirely on the behavior of JavaScript's Array.indexOf() implementation.
The end result depends entirely on the behavior of JavaScript's Array.indexOf() implementation.
Good catch. JWT is unicode out-of-the-box, which is really important to support non english user names and such.
If Auth0 is doing any sort of normalization they will definitely be vulnerable to all the normalization bugs from unicode. Would be a great follow up vulnerability.
If Auth0 is doing any sort of normalization they will definitely be vulnerable to all the normalization bugs from unicode. Would be a great follow up vulnerability.
The answer to that is we should not be using _any_ case-insensitive strings in protocols.
They are fine for human-visible names, but field names and internal enum values should use byte-by-byte comparison. It just makes entire class of vulnerabilities go away.
They are fine for human-visible names, but field names and internal enum values should use byte-by-byte comparison. It just makes entire class of vulnerabilities go away.
They are case-sensitive.
> 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.
> 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.
But the protocol says that they are case-insensitive! is not a good response to the assertion that machine-to-machine protocols should not be case-insensitive, which is what theamk said.
[deleted]
I think this points out that the semantics of trusting the header (which is still a part of the message) at all is flawed and leads to implementations getting it wrong and leaving gaps for attackers to exploit.
Blacklisting while you should have been whitelisting is harmful. Choose what you allow instead of trying to list what you don’t.
Without reading the article: any kind of blacklisting is considered harmful in security.
Always normalize your input?
Try:
Don't encode your machine-to-machine protocol as human-readable strings, leading to things like declaring machine-readable identifiers to be case-insensitive when only the humans need this, not the machines.
Don't encode your machine-to-machine protocol as human-readable strings, leading to things like declaring machine-readable identifiers to be case-insensitive when only the humans need this, not the machines.
eh, arbitrary protocols, sure.
But the web has always been human-readable and I don't want to change that. Therefore, you're gunna get serialized strings.
But the web has always been human-readable and I don't want to change that. Therefore, you're gunna get serialized strings.
Wired: {"alg":"nonE"}
The JOSE standards (including JWT) are a gift that keeps on giving to attackers.
I designed an alternative format in 2018 called PASETO, which doesn't contain the JOSE foot-guns. (I'm pushing for an IETF RFC this year.)
https://paseto.io
EDIT: Also, this affected their Authentication API rather than their JWT library.
If you use their JWT library, well, it certainly allows this kind of horrendous misuse... but it is not, per se, vulnerable.