Live data from Hacker News

Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

insomniasec.com

41–50 of 97 posts

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#41

Tired: {"alg":"none"} 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…

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.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#42

Tired: {"alg":"none"} 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…

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.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#43

Tired: {"alg":"none"} 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…

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.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#44

Tired: {"alg":"none"} 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…

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.

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.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#47

Tired: {"alg":"none"} 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…

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.

> 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.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#48

Earlier quoted context omitted.

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.

> 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.

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.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#49
post #27

Earlier quoted context omitted.

> 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.

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.

Post reply on HN