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.)
EDIT: Also, this affected their Authentication API rather than their JWT library.
If you use their JWT library, well, it certainly allows this kind of horrendous misuse... but it is not, per se, vulnerable.
But good work! With a RFC PASETO will be my choice for my next projects.
We had an infosec guy excitedly tell us that PASETO was the future, and we need to change to it right now. It looked good, and a way to avoid some of the possible JiWY issues in the same way having a TLS implementation that only allowed strong ciphers might.
But we have to integrate with so many third party pieces that require JWT it wasn't an option.
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.
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.
Or even just an opinionated library with some basic guardrails to prevent bad configurations.
JWT is the opposite of that. It's essentially a reenactment of the bad parts of 90s crypto, including RSA and NONE ciphers.
Oh hey look, he standardised POSIX threads. maybe everything bad is from POSIX?
"Everything bad has something to do with javascript"? Don't put words in my mouth.
"A C# developer at Microsoft" plus a javascript explosion. Aren't you just confirming my point? Those new people didn't materialise out of thin air, they may have been software developers who had to change focus rapidly. And they didn't necessarily knew how their creations could be misused under the rules of that new javascript world.
And he doesn't look old enough to be a designer of POSIX threads.
(if you don't like my expression about the "vibe" then I'll give you an example of a protocol with a C vibe: the type value would be a fixed-length field with a table of integer IDs written in the standard; everyone would complain about integer sign, wrap-arounds and the new extension field that was added because we ran out of IDs)
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...
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
It looks like Google's security team prefers the use of Tink[0] when having to encrypt things.
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?
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.
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.
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-...
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?
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 will fail-closed on those rules.
> A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?
Correct.
If your parser is set to check timestamps and one is invalid or omitted, it throws an exception.
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?
(googler opinions are my own)
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.
These are real, exploitable, and many of the fixes probably won't be backported.
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?
But before I resuscitate PASETO, XChaCha20 needs an RFC. It's pending IRTF kick-off.