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

101–110 of 140 posts

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

#101

Post by lvh »

zeveb wrote: post #97
lvh wrote: post #26

Earlier quoted context omitted.

> In general, I think that this is the wrong approach, because that means adding a database round-trip (which in a large system is almost certainly a network round-trip) for each and every API call. In general, asking a database for set membership is not close to the slowest thing applications do. > Notably, if the entire system is secured in depth (which large systems should be), it means adding a network round-trip…

> In general, asking a database for set membership is not close to the slowest thing applications do. From Jeff Dean's list of numbers every programmer should know[0], a round trip within the same datacenter takes on the order of 500,000 ns; a main memory reference is on the order of 100 ns. How often will an application be making an order of magnitude more than 5,000 main memory references to service a request? Some…

> From Jeff Dean's list of numbers every programmer should know[0], a round trip within the same datacenter takes on the order of 500,000 ns; a main memory reference is on the order of 100 ns. How often will an application be making an order of magnitude more than 5,000 main memory references to service a request? Sometimes, sure.

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.

Do you have a concrete description of what "online validation" specifically means for you, and how long it takes? How long does validating the token take instead?

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

#102

Post by _xnmw »

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.

VJWT: Versioned JWT

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

#103

Post by CiPHPerCoder »

timwis wrote: post #99

A common security issue I've seen with uses of JWT doesn't have to do with JWT itself but how it's used by front-end developers. It's commonly stored in localStorage instead of an HttpOnly cookie, which creates a cross-site scripting vulnerability. More details here: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo... Shockingly, the advice I've seen to protect against this by folks like Auth0 is "keep yo…

This is somewhat orthogonal to the security goals I'm trying to tackle, but still very relevant to the ecosystem that currently uses JWT.

So I've opened an issue to address it before v1.0.0 is tagged: https://github.com/paragonie/past/issues/14

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

#104

Post by saganus »

Shoothe wrote: post #79
saganus wrote: post #43

Earlier quoted context omitted.

I see. It makes sense. In this context then, what are your thoughts on minting tokens using Macaroons [0]? I ask because they seem to be of much lower complexity than JWTs since they just hash the data so no encryption algorithm negotiation or anything of the like, however they still meet your definition of minting a token. Obviously it would depend on a case-by-case basis to prefer macaroons over say a random token…

I did extensive research on various token types including Macaroons. While Macaroons look simple on the surface there are numerous edge cases that the verifier should take care of (Macaroons form a DAG because you can have multiple ones referencing each other). Plus there is symmetric decryption going on in case of third-party caveats. The caveat system can be very powerful (as caveats are just byte arrays you can us…

I've read about Macaroons and the lack of a standard to encode caveats (mainly from the google group about macaroons) but I'm interested in your take, so more details would be great!

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

#105

Post by davars »

lvh wrote: post #66
davars wrote: post #12

Earlier quoted context omitted.

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.

By downloading a shared key over TLS rather than the provider's public key?

No difference from the perspective of the token consumer. From the perspective of they token generator, it means rotating per-tenant keys rather than a single keypair.

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

#106

Post by lvh »

davars wrote: post #105
lvh wrote: post #66

Earlier quoted context omitted.

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

By downloading a shared key over TLS rather than the provider's public key? No difference from the perspective of the token consumer. From the perspective of they token generator, it means rotating per-tenant keys rather than a single keypair.

I addressed this elsewhere (https://news.ycombinator.com/item?id=16072690) but to quickly recap: that's not the hard problem, and hardened SAML IdPs that have the option of exploiting this turn out to have per-tenant keys anyway so that they can get cryptographic binding instead of counting on audience restrictions being checked.

Additionally, your TLS terminating stack is much better hardened than median in-app crypto code.

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

#107

Post by Shoothe »

saganus wrote: post #104
Shoothe wrote: post #79

Earlier quoted context omitted.

I did extensive research on various token types including Macaroons. While Macaroons look simple on the surface there are numerous edge cases that the verifier should take care of (Macaroons form a DAG because you can have multiple ones referencing each other). Plus there is symmetric decryption going on in case of third-party caveats. The caveat system can be very powerful (as caveats are just byte arrays you can us…

I've read about Macaroons and the lack of a standard to encode caveats (mainly from the google group about macaroons) but I'm interested in your take, so more details would be great!

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 even the official docs on libmacaroons have some weird choices, like encoding date in a ISO-like format (without timezone specifier at all). Also using UTF-8 is not that efficient if one could encode date as a number. Of course Macaroons are flexible and because the caveats are byte arrays you can use CBOR or whatever to conserve space. But then you lose compatibility. And you need compatibility if you want to utilize third party Macaroons (if a third party mints you a Macaroon with unknown caveat that makes the entire thing invalid). Third party Macaroons are the most powerful feature of the entire system but they introduce a lot of complexity: Macaroon references (look out for loops!), symmetric decryption and out of band communication needed to collect everything needed to authorize. That's why existing libraries allow only limited subset (e.g. no third party caveats referencing other third party Macaroons), and if you're writing a library (as I did) there is a lot of reverse engineering (e.g. libsodium is used in most libraries for symmetric encryption).

There are also some small things like de facto implementations using slightly different operations than the paper and a custom binary format. JWT just uses JSON and base64. (For the record I'm not a big fan of JWT).

What I like in Macaroons is the ability to further confine permissions. Sadly PAST doesn't seem to have something like this instead opting for a "safe JWT" way.

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

#108

Post by dkersten »

lvh wrote: post #101
zeveb wrote: post #97

Earlier quoted context omitted.

> In general, asking a database for set membership is not close to the slowest thing applications do. From Jeff Dean's list of numbers every programmer should know[0], a round trip within the same datacenter takes on the order of 500,000 ns; a main memory reference is on the order of 100 ns. How often will an application be making an order of magnitude more than 5,000 main memory references to service a request? Some…

> From Jeff Dean's list of numbers every programmer should know[0], a round trip within the same datacenter takes on the order of 500,000 ns; a main memory reference is on the order of 100 ns. How often will an application be making an order of magnitude more than 5,000 main memory references to service a request? Sometimes, sure. That argument is only valid if your application doesn't touch disk and doesn't touch th…

> 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, nobody will notice, but if I’m doing, say, a single non-local database lookup for the request then adding a second one for verification doubles the time it takes to service the request.

[1] I’m not saying that a network round trip and database lookup are slow, just that for the sake of this argument, they are being considered slow.

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

#109

Post by xir78 »

tptacek wrote: post #22
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).

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…

How do you support multiple keys and key rotation without using RS256?

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

#110

Post by lvh »

dkersten wrote: post #108
lvh wrote: post #101

Earlier quoted context omitted.

> From Jeff Dean's list of numbers every programmer should know[0], a round trip within the same datacenter takes on the order of 500,000 ns; a main memory reference is on the order of 100 ns. How often will an application be making an order of magnitude more than 5,000 main memory references to service a request? Sometimes, sure. That argument is only valid if your application doesn't touch disk and doesn't touch th…

> 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?
Post reply on HN