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

131–140 of 140 posts

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

#131

Post by allyant »

AndrewStephens wrote: post #83
allyant wrote: post #52

Earlier quoted context omitted.

Just a small 'way forward' for those wanting to have the ability to revoke a JWT after I came up with a solution on my last project: A 'Gateway' - use OpenResty to verify the JWT ID stored in a redis cache using a proxy pass. When the Authentication service grants a JWT add its ID to this cache along with a way of identifying the user. That way the entire advantage/disadvantage of decentralised authentication is not…

Forgive my ignorance, but if you are going to all the trouble of storing the JWT id in a server side database for verification why don't you just store the JWTs' claims as well and just hand the client an opaque random id? Your gateway could do the lookup and supply the claims to your backend without the client knowing anything about it. You wouldn't even have to validate the claims, since they never leave your serve…

Good solution! Openresty could create the JWT and add it to the forwarding headers, although the user would still need a cookie to maintain session with the proxy.

Only disadvantage I could see would be performance.

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

#132

Post by Shoothe »

saganus wrote: post #124
Shoothe wrote: post #107

Earlier quoted context omitted.

If you compare it to JWT in JWT claims are basically a string name (like "exp") and a JSON value. It's pretty simple. You need to check of the value for exp is a number and is greater than current millis. In Macaroons the entire caveat (a.k.a. claim) is just a byte array. The majority of libraries use predicates "X op Y" encoded in UTF-8 (e.g. time Unfortunately that's where the simplicity of Macaroons end because ev…

Awesome, thanks for the details. One of the issues that I saw being discussed on the forums was precisely the lack of a standard format for caveats and even some suggestions to create one. I think it's a very cool project but for some reason I don't think it has caught on. Do you think if someone came up with a suitable standard built it would see broader use? or what is your take on the lack of interest (IMHO) for t…

Macaroons have many moving pieces, caveats being just one of them. Standardization would have to approach it from all edges. For example the binary format while simple is also "de facto" standard resembling protobuf but not exactly. Maybe CBOR would be a good idea (or a subset of it)?

As for caveats there are two forces at place: some want simple format ("X op Y") but there is another way that I've explored in a PoC - use simple stack-based script system (similar to Bitcoin Script [0]), then you can encode some really interesting properties inside your tokens (like requiring hashes of different properties, or signatures) so it would be kind of a meta-authorization scheme where you can delay the decision (e.g. require EC signatures for some sensitive operations). Of course this brings additional complexity but on the other hand using caveats in "X op Y" form doesn't bring any benefits over JWT claims.

[0]: https://en.bitcoin.it/wiki/Script

The ultimate reason why I abandoned Macaroons (after working for some prototypes and creating a JS library for them) is just the amount of complexity needed to work with them. And remember - code working with Macaroons is being executed before the request is authorized (that's what they are for) so this code need to be carefully audited and any bug can have severe consequences.

Compare that with JWT, you can write a verifier in simple code (JSON and base64 are built-in in any language) and simple is easier to audit. In Macaroons you first need to decode base64, parse custom binary format, check consistency (no cycles in third-party caveats), decrypt third-party keys. Moreover there can be multiple Macaroons for given ID, you need to check if at least one satisfies the request. Better - check all of them and then see if at least one works (to protect against side-channel attacks). So there is some inherent complexity in the entire stack. Removing it would require some substantial work. IMHO that's why they are not widely used. Oh, did I mention the existing libraries have some rather significant issues [1]?

[1]: https://github.com/nitram509/macaroons.js/blob/master/src/ma...

So to answer your question: I would gladly see some standarization effort, but it needs to be really thorough to have good effect. Unfortunately Macaroons are already plagued by old cruft (e.g. third-party caveats ID are called "cid" and first party caveats are also called "cid" but they are completely different) that no-one wants to touch not to break existing code.

If you don't mind we can keep the discussion here, it's good for others to see (I got into Macaroons because of one of these threads) and it's google-able :)

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

#133

Post by zimpenfish »

atmosx wrote: post #71
zimpenfish wrote: post #34

Earlier quoted context omitted.

But that also means you're missing the opportunity to educate the rest of the HN readers who would like to understand -why- something is bad (like me because we're rolling out public key JWTs). Even just a link to a blog post would be better than just "because I'm me and people agree".

Here: https://storify.com/jcuid/thomas-h-ptacek-don-t-use-json-web... https://news.ycombinator.com/item?id=13866883 https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/ or go with the flow: https://www.google.gr/search?q=ptacek+jwt&oq=ptacek+jwt&aqs=... He has countless comments preaching against JWT and DNSSEC. Mind you, I know the nickname, I know he is good with sec (I'd hire him to vet an app) and all but…

The HN link doesn't explain why public key JWTs are bad; it's just more "don't use JWTs" (with the exceptionally unhelpful "as engineers, you need to understand first and foremost that JWT is bad". How can we understand if all we get is "JWT is bad because I say it is"?)

The Storify link is slightly more useful but again doesn't really explain anything - it's just bullet points of "I think these things are bad in a standard" which is great if you already have the knowledge of those things. Utterly useless otherwise.

And if "implementation errors should lower your opinion of a specification" means we shouldn't use JWT, where does that leave us on WIFI, SSL, HTTP, speculative execution in pipelines, ...?

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

#134

Post by dkersten »

lvh wrote: post #110
dkersten wrote: post #108

Earlier quoted context omitted.

> That argument is only valid if your application doesn't touch disk and doesn't touch the network to go talk to some other service anyway. Why? Adding another source of “slowness”[1] isn’t free just because other sources of “slowness” already exist, especially if it’s already close to being unacceptably slow as it is. I mean, sure, if the request takes ten minutes anyway and the validation check takes a few seconds,…

Do you have specific performance data for a comparable token validation?

I’m not really arguing against your point, just pointing out that your statement isn’t necessarily true. You said that if you do any network or disk access then validation will be negligible as it would be dominated by that. I’m simply saying that while this is probably true in most real world cases, it may not be so if for example both validation and normal request handling do a simple database query, then validation is 50% of the request time (or 25% if the request takes twice as long etc). Since the person you were relying to above said something about performance sensitivity, this overhead could be too much.

Having said that, I do believe that what you’re saying is the right approach for 99.9% of use cases and I would imagine that in almost all cases the performance hit really is negligible.

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

#135

Post by tptacek »

zimpenfish wrote: post #133
atmosx wrote: post #71

Earlier quoted context omitted.

Here: https://storify.com/jcuid/thomas-h-ptacek-don-t-use-json-web... https://news.ycombinator.com/item?id=13866883 https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/ or go with the flow: https://www.google.gr/search?q=ptacek+jwt&oq=ptacek+jwt&aqs=... He has countless comments preaching against JWT and DNSSEC. Mind you, I know the nickname, I know he is good with sec (I'd hire him to vet an app) and all but…

The HN link doesn't explain why public key JWTs are bad; it's just more "don't use JWTs" (with the exceptionally unhelpful "as engineers, you need to understand first and foremost that JWT is bad". How can we understand if all we get is "JWT is bad because I say it is"?) The Storify link is slightly more useful but again doesn't really explain anything - it's just bullet points of "I think these things are bad in a s…

To me, this rebuttal reads, "I don't understand it, ergo it must be dubious".

I'm criticizing JWT. Not you, or any other developer. If you don't understand or follow or agree with my criticism, that's OK. We can still live our lives.

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

#136

Post by zimpenfish »

tptacek wrote: post #135
zimpenfish wrote: post #133

Earlier quoted context omitted.

The HN link doesn't explain why public key JWTs are bad; it's just more "don't use JWTs" (with the exceptionally unhelpful "as engineers, you need to understand first and foremost that JWT is bad". How can we understand if all we get is "JWT is bad because I say it is"?) The Storify link is slightly more useful but again doesn't really explain anything - it's just bullet points of "I think these things are bad in a s…

To me, this rebuttal reads, "I don't understand it, ergo it must be dubious". I'm criticizing JWT. Not you, or any other developer. If you don't understand or follow or agree with my criticism, that's OK. We can still live our lives.

> To me, this rebuttal reads, "I don't understand it, ergo it must be dubious".

That is not intended - it's more "I don't understand it, I'm happy to believe it's broken but all we get is Appeal To (self)Authority as to why rather than actual usefulness."

> If you don't understand or follow or agree with my criticism, that's OK. We can still live our lives.

Well, sure, but wouldn't you prefer to help people who don't understand by actually explaining something for once?

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

#137

Post by yuhong »

grogenaut wrote: post #24
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…

Your points sound very interesting but don't provide any details. Could you provide more details, I'm interested in learning about this. For instance is there a good resource you use on what are good alternatives when you think you need to use PKI when in fact there are better alternatives? Is there a good resource on how to use JWT correctly that you trust? (Edited-tone, was a bit more aggressive but was pointing ou…

JWS and JWE aren't as bad as JWT itself. You can use them without the JWT header.

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

#138

Post by lvh »

dkersten wrote: post #134
lvh wrote: post #110

Earlier quoted context omitted.

Do you have specific performance data for a comparable token validation?

I’m not really arguing against your point, just pointing out that your statement isn’t necessarily true. You said that if you do any network or disk access then validation will be negligible as it would be dominated by that. I’m simply saying that while this is probably true in most real world cases, it may not be so if for example both validation and normal request handling do a simple database query, then validatio…

I gave specific examples of relative latency going the other direction in GP thread. But yes: not only is it not actually slow, it’s a much simpler engineering exercise to make it fast (see caching argument, same thread).

Is it literally definitionally impossible that minted tokens have a useful application? No, of course not. But absent very specific cases I’m going to argue for the thing that’s safe, fast & simple :-D

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

#140

Post by logicuce »

lvh wrote: post #70
logicuce wrote: post #62

Earlier quoted context omitted.

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'…

It is not a bug with Google but instead a problem with "B" as they choose to ignore the "aud" part of the token.

You can't say password based authentication is bad because some developers choose to store password in plain text. The blame squarely lies with the developer.

People implementing auth without willing to go a little deeper may hurt themselves.

Post reply on HN