Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful • Hacker News Board

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

#91

Post by e12e » Fri, Apr 17, 2020, 9:58 AM UTC

CiPHPerCoder wrote: post #73

e12e wrote: post #72

Earlier quoted context omitted.

Thanks for the pointers - I'd looked at that, I think, but missed the add-rule bit. But to be clear, it's easy to set up the validating service so that it accepts a token with expired timestamp as valid - it's the default to not check the timestamp if present? A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?

The default is to not enforce any rules beyond the cryptographic signatures. If you need any other validations, it's entirely up to you to specify what those are. You might care about checking `exp`, but I might instead care about `iat` with a hard-coded token lifetime. PASETO supports whatever zany business logic developers need, but doesn't enforce anything by default. But once you add a rule to your parser, it wil…

OK. I think a brief paragraph along these lines probably should be in (one of) the readme(s).

Personally I think temporal validity really is needed in most cases - and probably should be default. I suppose maybe not for use as long lived api-keys. Then again... infinent validity is almost certainly wrong..

From time to time I wonder how I'd implement kerberos for the web today - probably trading shared secrets for public key/anchoring trust in certificates... And I usually end up realizing it likely will end up just as complex as kerberos5, with similar trade-off/weaknesses (eg ticket hijack).

Maybe paseto has different goals (which is fine) - and maybe it makes sense as a building block - but I think I'd like to see a simple toke spec that demands: valid keys/certs, blacklist/revocation, temporal validity (the simplest is probably a valid from/to on the token). And no crypto algo agility/negotiation etc.

What is the prime motivation behind/use case/goal for paseto?

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

#92

Post by joepie91_ » Fri, Apr 17, 2020, 10:54 AM UTC

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.

I mean, "basic guardrails" is basically exactly what Auth0 tried to do here with their algorithm check, and see how that turned out.

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

#93

Post by joepie91_ » Fri, Apr 17, 2020, 10:57 AM UTC

There's actually three lessons to be drawn from this incident:

1. Don't use JWT, it's too easy to mess up.

2. If you're trying to fence off some sort of format or API, whitelist things, don't blacklist them.

3. This narrative that "you should use a third-party authentication provider because they're security experts and are much less likely to get it wrong"... well... I think you can see where I'm going with this.

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

#94

Post by different_sort » Fri, Apr 17, 2020, 12:45 PM UTC

CiPHPerCoder wrote: post #44

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.

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.

Thank you for your reply!

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

#95

Post by eximius » Fri, Apr 17, 2020, 4:20 PM UTC

JdeBP wrote: post #83

eximius wrote: post #4

Always normalize your input?

Try: Don't encode your machine-to-machine protocol as human-readable strings, leading to things like declaring machine-readable identifiers to be case-insensitive when only the humans need this, not the machines.

eh, arbitrary protocols, sure.

But the web has always been human-readable and I don't want to change that. Therefore, you're gunna get serialized strings.

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

#96

Post by hinkley » Fri, Apr 17, 2020, 5:01 PM UTC

user5994461 wrote: post #61

hinkley wrote: post #53

Earlier quoted context omitted.

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.

I would argue the opposite. openSSL is such a can of worms at this point that if you suggested this sort of magic thinking in a design meeting, you'd have a fight on your hands and I wouldn't be the only person arguing with you.

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

#97

Post by kyrra » Wed, Apr 22, 2020, 1:28 PM UTC

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…

To come back to one other point. Why Google payments uses PGP: because all other payment companies in the world do too. We work with many different companies, and when dealing with files, they all figured out how to use PGP 20+ years ago and probably won't change unless they are forced to. :)

(googler opinions are my own)