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

31–40 of 97 posts

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

#31

Post by karatestomp »

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…

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!"

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

#32

Post by OatMilkLatte »

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

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

#33

Post by kyrra »

CiPHPerCoder wrote: post #22
kyrra wrote: post #21

Earlier quoted context omitted.

(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: ht…

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

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

#34

Post by CiPHPerCoder »

kyrra wrote: post #33
CiPHPerCoder wrote: post #22

Earlier quoted context omitted.

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: ht…

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

Yes, Tink is acceptable too. :)

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

#35

Post by cordite »

kyrra wrote: post #33
CiPHPerCoder wrote: post #22

Earlier quoted context omitted.

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: ht…

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

Tink is great! I wish there were more supported languages. AEAD and AWS KMS to decrypt the key set is perfect for our needs.

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

#36

Post by tptacek »

CiPHPerCoder wrote: post #20
ucarion wrote: post #19

Earlier quoted context omitted.

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.

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

#37

Post by CiPHPerCoder »

tptacek wrote: post #36
CiPHPerCoder wrote: post #20

Earlier quoted context omitted.

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.

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

#38

Post by user5994461 »

karatestomp wrote: post #31
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…

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.

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

#39

Post by different_sort »

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.

"trusted server"

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

#40

Post by karatestomp »

user5994461 wrote: post #38
karatestomp wrote: post #31

Earlier quoted context omitted.

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…

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?
Post reply on HN