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

51–60 of 97 posts

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

#51

Post by wongarsu »

Arnout wrote: post #29
applecrazy wrote: post #25

Earlier quoted context omitted.

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.

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

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

#52

Post by hinkley »

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…

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.

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

#53

Post by hinkley »

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…

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.

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

#54

Post by tptacek »

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

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

#55

Post by XMPPwocky »

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

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

#56

Post by XMPPwocky »

XMPPwocky wrote: post #55
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 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 s…

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.

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

#57

Post by stock_toaster »

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…

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?

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

#58

Post by inopinatus »

different_sort wrote: post #41
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…

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.

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.

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

#59

Post by CiPHPerCoder »

stock_toaster wrote: post #57
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…

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.

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

#60

Post by blattimwind »

pillfill wrote: post #47
different_sort wrote: post #41

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.

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.

Post reply on HN