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

31–40 of 140 posts

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

#31

Post by grogenaut »

tptacek wrote: post #29
grogenaut wrote: post #24

Earlier quoted context omitted.

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…

I'm pretty comfortable with the makeup of the subset of HN readers that take me seriously and/or understand where I'm coming from, and so I'm going to avoid litigating with strangers on this one.

I'd still love to know the details.

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

#32

Post by atonse »

jcadam wrote: post #23
atonse wrote: post #13

Earlier quoted context omitted.

Just to clarify, it isn't limited to that suite, but it has a default whitelist of only allowing it. So I COULD change it, but I didn't. "Why did you use JWT to begin with? (What does minting tokens buy you?)" Absolutely no compelling reason apart from: - Never want to roll my own auth, and there were already libraries in elixir and ember to work with JWT, so easy to cobble together - The HS512 stuff seemed secure en…

Yea, I'm using JWT for authentication, but I still find myself doing a db query for the 'authorization' piece (so I don't bother putting any 'role' information in the JWT, since that seemed rather a bad idea to me, anyway). Still don't have a great solution for revoking tokens before they expire. At least it's stateless :)

Revocation isn't such a big deal if you have short lifetimes in your tokens and do auto-refresh (which is quite easy to do in a single page app)

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

#33

Post by CiPHPerCoder »

grogenaut wrote: post #25
lvh wrote: post #15

Earlier quoted context omitted.

Getting the encryption right is pretty tricky! How do you verify the encryption method for a message, for example? That's a real problem in JWT: that's how RSA privkeys leak. PAST solves this by not negotiating. How do you make sure nobody's doing nonce reuse in ECDSA? That's a real problem in JWT. PAST solves this by only having (v2) specify exactly how to do that. Just because this specifies a format, doens't mean…

Sure but to the GP's question, the format of json vs pipe delimted strings is not the problem, it's WHAT you put in the Json or string and what it allows (eg configuration) that is the problem, correct? GP: Basically PAST is just limiting your options down to things we think are secure combinations and eliminating things we know are insecure. However it does this with WHAT it puts in the JSON, not that it's JSON vs a…

This might also be of interest: https://github.com/paragonie/past/tree/master/docs/02-PHP-Li...

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

#34

Post by zimpenfish »

tptacek wrote: post #29
grogenaut wrote: post #24

Earlier quoted context omitted.

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…

I'm pretty comfortable with the makeup of the subset of HN readers that take me seriously and/or understand where I'm coming from, and so I'm going to avoid litigating with strangers on this one.

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

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

#35

Post by CiPHPerCoder »

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.

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

#36

Post by sumnulu »

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…

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

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

#37

Post by owenmarshall »

tptacek wrote: post #29
grogenaut wrote: post #24

Earlier quoted context omitted.

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…

I'm pretty comfortable with the makeup of the subset of HN readers that take me seriously and/or understand where I'm coming from, and so I'm going to avoid litigating with strangers on this one.

So I trust you completely here - but I lack the crypto chops to understand why that’s the case, and I’m interested in understanding.

Do you have any good recommended primers that’d help me get it?

Or should I just get off my arse and finally do cryptopals? ;-)

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

#38

Post by CiPHPerCoder »

Daycrawler wrote: post #20

This doesn't solve the criticism against JWT being used for sessions, which is one of the main point against JWT expressed in the very site linked at the top of the README.

There's nothing I can do at this layer that will stop people from using JWT/PAST/etc. as an attempt to build stateless session management systems for some ill-conceived "horizontal scalability" requirements, except maybe continue to tell people this is a bad idea and don't do that.

The rest of the points (i.e. the problems with the JOSE standards) are what PAST seeks to solve. The "do not misuse" problem is more complicated, and if I were to add e.g. "do not use this for stateless sessions" at the top in big red letters, that will only tell developers "this is unsafe, keep using JWT instead".

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

#39

Post by tptacek »

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.

No, that's not what I mean.

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

#40

Post by enobrev »

CiPHPerCoder wrote: post #38
Daycrawler wrote: post #20

This doesn't solve the criticism against JWT being used for sessions, which is one of the main point against JWT expressed in the very site linked at the top of the README.

There's nothing I can do at this layer that will stop people from using JWT/PAST/etc. as an attempt to build stateless session management systems for some ill-conceived "horizontal scalability" requirements, except maybe continue to tell people this is a bad idea and don't do that. The rest of the points (i.e. the problems with the JOSE standards) are what PAST seeks to solve. The "do not misuse" problem is more comp…

> that will only tell developers "this is unsafe, keep using JWT instead".

That's a good point. Maybe a header in the readme/docs like "Stateless Sessions", followed by "Using PAST/JWT/etc. for stateless sessions is a terrible idea, because kittens will die needlessly and painfully [ obviously using an actual summary of why ]. Don't just take my word for it, here are some resources explaining further..."

Post reply on HN