Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

insomniasec.com

Post reply on HN
Print view View original

61–70 of 97 posts

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

#61

Post by user5994461 »

hinkley wrote: post #53
user5994461 wrote: post #38

Earlier quoted context omitted.

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…

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.

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.

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

#62

Post by dwaite »

CiPHPerCoder wrote: post #2

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…

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

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

#63

Post by user5994461 »

applecrazy wrote: post #5
rvz wrote: post #3

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 firs…

> 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 gi…

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.

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

#64

Post by user5994461 »

CiPHPerCoder wrote: post #18
applecrazy wrote: post #5

Earlier quoted context omitted.

> 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 gi…

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

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.

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

#65

Post by griffinmb »

user5994461 wrote: post #64
CiPHPerCoder wrote: post #18

Earlier quoted context omitted.

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

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 excl…

It’s versioned, which is an improvement on “agility”

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

#66

Post by e12e »

CiPHPerCoder wrote: post #59
stock_toaster wrote: post #57

Earlier quoted context omitted.

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?

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.

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.

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

#67

Post by theamk »

gjvnq wrote: post #12

What if someone used the correct case but weird Unicode characters? I mean, if "none" = "nonE", is "none" = "ｎｏｎｅ"

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.

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

#68

Post by thinkshiv »

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.

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

#70

Post by CiPHPerCoder »

e12e wrote: post #66
CiPHPerCoder wrote: post #59

Earlier quoted context omitted.

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.

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 protectio…

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

Post reply on HN