Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: PAST, a secure alternative to JWT

github.com

Post reply on HN
Print view View original

61–70 of 140 posts

Re: Show HN: PAST, a secure alternative to JWT

#61

Post by lvh »

davewritescode wrote: post #55
giaour wrote: post #45

Earlier quoted context omitted.

I think you're conflating the 'seal' and 'sign' use cases. I'm not sure how one could design a secure system where encrypted cookies could either be read by everyone (encrypted with private key) or forged by everyone (encrypted with public key), but using public keys to validate that an attestation was signed by a trusted third party is both sound and commonplace. For example, this is how identity tokens from AWS Cog…

Was just going to post this, JWT with public keys is very handy for stateless verification of claims, which is what it seems was the primary motivator of the spec. As someone who had to work with XML-DSIG, JWT seems less bad :)

You don't need public-key crypto to do stateless verification of claims. Secret-key crypto does that just fine. You need public-key crypto if you want _other people_ to be able to verify the claims -- that's an important distinction, because it specifies what you're buying for your much more complicated crypto.

Re: Show HN: PAST, a secure alternative to JWT

#62

Post by logicuce »

cmsd2 wrote: post #10
tptacek wrote: post #4

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

Google OAuth 2 tokens are also RS256 JWTs

Re: Show HN: PAST, a secure alternative to JWT

#63

Post by dullgiulio »

sumnulu wrote: post #36
tptacek wrote: post #22

Earlier quoted context omitted.

This is the logic people use when they encrypt cookies to public keys. I've never tested a system with public key encrypted cookies that wasn't broken. As a general rule of thumb: public key is what you use when you have no other choice. PAST mitigates the risk somewhat by hardcoding a public key system into its version. But I'm still recoiling from the kind of first-principles mixing of systems security and cryptogr…

> As a general rule of thumb: public key is what you use when you have no other choice. I think you mean, "private" key is what you use when you have no other choice.

I think "public key" as in "asymmetric cryptography with public key."

Re: Show HN: PAST, a secure alternative to JWT

#64

Post by giaour »

lvh wrote: post #60
giaour wrote: post #45

Earlier quoted context omitted.

I think you're conflating the 'seal' and 'sign' use cases. I'm not sure how one could design a secure system where encrypted cookies could either be read by everyone (encrypted with private key) or forged by everyone (encrypted with public key), but using public keys to validate that an attestation was signed by a trusted third party is both sound and commonplace. For example, this is how identity tokens from AWS Cog…

I don't understand the conflation. 'tptacek is arguing that you preferentially use secret-key crypto to public-key crypto, because public-key crypto is significantly more precarious. It seems like you are raising a new point, not arguing with his.

tptacek was saying everyone should be cautious about PKI-based JWTs and provided encrypted cookies as an example of something that is rarely (if ever) implemented safely and securely with PKI cryptography. My point is that while the 'seal' function of PAST may be of questionable value, the 'sign' function is not. I think it's important to disambiguate those two uses of asymmetric cryptography.

Re: Show HN: PAST, a secure alternative to JWT

#65

Post by cdubzzz »

CiPHPerCoder wrote: post #35
idbehold wrote: post #30

I do wish a different acronym had been chosen. When I search for "[language of choice] JWT" pretty much all results are relevant. But even if this new token schema takes off it will forever be a hassle to find relevant results for "[language of choice] PAST".

I spent two weeks (my Christmas vacation) working on rough drafts for several problems I wanted to solve in 2018. PAST was one of items I listed. (The list is here: https://github.com/paragonie-scott/public-projects/issues/6 ) 99.9% of that time was spent trying to come up with a better name/acronym, without success. I decided to just give it a plain/obvious name until a better one surfaced.

Maybe just change "agnostic" to "neutral": PNST? "Independent" is probably better, but PIST may not be so great a choice (:

Re: Show HN: PAST, a secure alternative to JWT

#66

Post by lvh »

davars wrote: post #12
eadmund wrote: post #9

Earlier quoted context omitted.

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

Also, issuing servers and verifying servers don't even need to be part of the same organization, allowing you to outsource credential management (see Auth0, Firebase Authentication).

You can do that fine with secret-key cryptography too.

Re: Show HN: PAST, a secure alternative to JWT

#67

Post by lvh »

giaour wrote: post #64
lvh wrote: post #60

Earlier quoted context omitted.

I don't understand the conflation. 'tptacek is arguing that you preferentially use secret-key crypto to public-key crypto, because public-key crypto is significantly more precarious. It seems like you are raising a new point, not arguing with his.

tptacek was saying everyone should be cautious about PKI-based JWTs and provided encrypted cookies as an example of something that is rarely (if ever) implemented safely and securely with PKI cryptography. My point is that while the 'seal' function of PAST may be of questionable value, the 'sign' function is not. I think it's important to disambiguate those two uses of asymmetric cryptography.

Gotcha, thanks! That makes more sense now.

I agree that they're worth examining separately, but the more general point still stands that there is a lot more that can go wrong with sign than with aead. The arguments for broken RSA-encrypted cookies apply similarly to broken signed cookies. It's not clear to me for example that an invalid curve attack against seal is intrinsically worse than a nonce (ab|re)use bug against ECDSA.

Re: Show HN: PAST, a secure alternative to JWT

#69

Post by lxe »

I really don't get the whole "the spec supports choosing of algorithm, therefore the whole implementation is bad"

If my server-side application sends a JWT with a "good" algorithm, and disallows any other alg's, wouldn't that prevent attacks?

Why do we need a whole new implementation?

Re: Show HN: PAST, a secure alternative to JWT

#70

Post by lvh »

logicuce wrote: post #62
cmsd2 wrote: post #10

Earlier quoted context omitted.

really? both Azure AD and AWS Cognito use RS256 as the only algorithm supported. perhaps my sample size is small.

Google OAuth 2 tokens are also RS256 JWTs

The requirements and budget of Google, Amazon and Microsoft are very different from a median start-up.

A simple closely related field: OAuth 2 token replay attacks. I auth against A with Facebook, A uses token to impersonate me against B. ISTR Google had basically the same bug. A median startup will not find that bug. Storing a random token in a database? Very likely they won't mess that one up. Also, if you do (let's say your randomness generator is MT as opposed to a CSPRNG), it's easy to fix, because you control the validation endpoint.

Post reply on HN