Show HN: PAST, a secure alternative to JWT
1–10 of 140 posts
Re: Show HN: PAST, a secure alternative to JWT
#2This looks promising, and it's from a very well respected security researcher.
Re: Show HN: PAST, a secure alternative to JWT
#3This is great. Having versions instead of kitchen sinks, and having those versions get rid of the footguns, is exactly what fixes the cryptographic JWT perils.
Note: you probably still just want a random key in a database. And revocation is still an issue. But if you’re absolutely sure you want to mint tokens...
Re: Show HN: PAST, a secure alternative to JWT
#4This is better than JWT. In particular: the whole protocol is versioned, rather than serving as a metaprotocol that negotiates the underlying cryptography. If you speak "v2" of this protocol, and refuse to accept any other version, then you're getting a token that is basically just Nacl.
My only nit --- apart from the "auth enc seal sign" names, which aren't coherent --- is why do public key at all? Yes, Nacl supports it, but that doesn't mean the token format does. What's the use case for it? Who's asking for it? Specifically who? The overwhelming majority of JWT implementations I see aren't public key (except for the fact that the format is negotiated and might be tricked into being that).
Why not punt "seal" and "sign" into a "v3", when/if it's needed?
Re: Show HN: PAST, a secure alternative to JWT
#5This is better than JWT. In particular: the whole protocol is versioned, rather than serving as a metaprotocol that negotiates the underlying cryptography. If you speak "v2" of this protocol, and refuse to accept any other version, then you're getting a token that is basically just Nacl. My only nit --- apart from the "auth enc seal sign" names, which aren't coherent --- is why do public key at all? Yes, Nacl support…
> My only nit --- apart from the "auth enc seal sign" names, which aren't coherent --- is why do public key at all?
> Why not punt "seal" and "sign" into a "v3", when/if it's needed?
Would you be happier seeing something like this?
- v1: HMAC-SHA2, AES-CTR+HMAC-SHA2
- v2: RSA and all its sins
- v3: Libsodium crypto_aead_*
- v4: Libsodium crypto_{box,sign}_*
The only use-case I'm aware of as of this morning is OAuth2 users who currently use JWT for access tokens. https://bshaffer.github.io/oauth2-server-php-docs/overview/j...
Re: Show HN: PAST, a secure alternative to JWT
#6I'm not a security expert but when I looked into JWT I was terrified at how easy it was to screw up. Glad to see I'm not the only one.
Re: Show HN: PAST, a secure alternative to JWT
#7I have implemented JWT on my app but the library I used (Guardian, written in Elixir), only allows you to use HMAC-SHA512 by default. And I've left it that way.
Should I still be worried? I get that JWT's algorithm flexibility is overall a bad thing, but if I only allow one, should I continue to worry?
Re: Show HN: PAST, a secure alternative to JWT
#8This is better than JWT. In particular: the whole protocol is versioned, rather than serving as a metaprotocol that negotiates the underlying cryptography. If you speak "v2" of this protocol, and refuse to accept any other version, then you're getting a token that is basically just Nacl. My only nit --- apart from the "auth enc seal sign" names, which aren't coherent --- is why do public key at all? Yes, Nacl support…
> In particular: the whole protocol is versioned, rather than serving as a metaprotocol that negotiates the underlying cryptography.
In my view, that's one of the big takeaways from early cryptographic protocols: complex handshake negotiations just won't be secure, so just don't. The other is that crypto code should ideally not contain any parsing at all.
e: Well that and the whole debacle on the level of primitives and operation modes of course.
Re: Show HN: PAST, a secure alternative to JWT
#9This is better than JWT. In particular: the whole protocol is versioned, rather than serving as a metaprotocol that negotiates the underlying cryptography. If you speak "v2" of this protocol, and refuse to accept any other version, then you're getting a token that is basically just Nacl. My only nit --- apart from the "auth enc seal sign" names, which aren't coherent --- is why do public key at all? Yes, Nacl support…
We use public-key JWTs so that the verifying servers do not have a copy of the secret key, just the authorisation server's public key. That prevents a compromise of the verifying servers from also compromising the entire system (yes, a compromised verifying server can be made to do anything it's allowed to do — but that's still less than everything).
Re: Show HN: PAST, a secure alternative to JWT
#10This is better than JWT. In particular: the whole protocol is versioned, rather than serving as a metaprotocol that negotiates the underlying cryptography. If you speak "v2" of this protocol, and refuse to accept any other version, then you're getting a token that is basically just Nacl. My only nit --- apart from the "auth enc seal sign" names, which aren't coherent --- is why do public key at all? Yes, Nacl support…
really?
both Azure AD and AWS Cognito use RS256 as the only algorithm supported.
perhaps my sample size is small.