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

21–30 of 97 posts

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

#21

Post by kyrra »

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…

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

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

#22

Post by CiPHPerCoder »

kyrra wrote: post #21
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…

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

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

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

#23

Post by rvz »

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…

> 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

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

#24

Post by grinich »

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 think we're going to use PASETO for some stuff at WorkOS. Thanks for building it. :)

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

#25

Post by applecrazy »

Arnout wrote: post #15
applecrazy wrote: post #13

Earlier quoted context omitted.

> 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

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.

Just wanted to point out the supreme irony: Auth0 wrote that library.

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

#26

Post by tptacek »

applecrazy wrote: post #13
Arnout wrote: post #8

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

> 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

Does it also have the option to blacklist algorithms? Because if so, people are going to use that option.

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

#27

Post by jaywalk »

wereHamster wrote: post #10
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 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.

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

#29

Post by Arnout »

applecrazy wrote: post #25
Arnout wrote: post #15

Earlier quoted context omitted.

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.

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.

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

#30

Post by xianb »

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

Post reply on HN