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

81–90 of 140 posts

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

#81

Post by irq-1 »

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.

Refer to it with a version number: PAST2, PAST3, etc..

You could also drop the use mapping: change 'sign' to 'public-auth' and explain that it's a 'sign' operation (a.k.a. digital signatures)

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

#82

Post by WorldMaker »

lxe wrote: post #69

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?

There's also the issue that the alg field is in an encoded section of the JWT payload and has to be base64-decoded and then JSON parsed. There have been buffer overrun and malicious JSON attacks on JWT.

PAST at least moves that to a clear text prefix in the vx.scheme pattern. Theoretically, that doesn't even stop it from having a v0.none or some other dumb algorithm such as JWT allows in a bad version suite, but it does at least mitigate against decryption attacks.

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

#83

Post by AndrewStephens »

allyant wrote: post #52
lvh wrote: post #3

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

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

The best part of using JWTs is that you can validate without a central database. If you need a central database for sessions anyway you might as well store the claims in it.

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

#84

Post by jwtfail »

allyant wrote: post #52
lvh wrote: post #3

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

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…

Congratulations, you’ve just invented session tokens. Don’t get me wrong: stateless tokens (like JWT) are terrible in part because they’re irrevocable, but then why bother reimplementing session tokens with JWT? Just use plain old session tokens instead.

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

#85

Post by jcadam »

lvh wrote: post #72
jcadam wrote: post #54

Earlier quoted context omitted.

Well, not much from a security standpoint. But I rather don't enjoy dealing with statefulness on the server, so I try to minimize it wherever possible.

Why is the server stateless? I thought you said you end up calling up the db all the time for authz decisions anyway. That sounds like you're still managing a bunch of state server-side. Unless you're saying "my server process itself is stateful, all the state lives in the database": in which case, yes, but the tokens bought you nothing. If you have random tokens and you store them in the database you have the same s…

Yes, there's a database (pgsql) for persistence, though no 'session state' is stored there. All of the middleware/services are stateless.

And yes, I realize now that I could accomplish much the same thing without using JWT (a decision made some time ago, when everyone was raving about JWT), but I've got bigger priorities than ripping up my auth system (which to the best of my knowledge is working acceptably well) ATM.

But I do plan to take a look at it and perhaps migrate to something else in the future :)

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

#86

Post by CiPHPerCoder »

treve wrote: post #77
CiPHPerCoder wrote: post #38

Earlier quoted context omitted.

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…

Why is this a bad idea exactly? I'm still very interested in the idea of using stateless sessions. Is it just that it's hard to expire sessions server-side, or is there more to it?

I've written about this at length here: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

(It's also the first link in the README for the project this Show HN is linking to, FWIW)

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

#87

Post by JepZ »

lxe wrote: post #69

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?

I am totally with you. For me JWT is the idea to store encrypted values client-side which you can use to authenticate the client and is different to the old way of just storing a random 'dumb' session id with the linked values somewhere on the server.

So yes, I appreciate secure and easy-to-use implementations of that idea, but always going for how insecure JWTs are, just because there are easy ways to do it wrong, is like telling everybody that password logins are bad because some people implemented them in flash.

> Why do we need a whole new implementation?

I think the problem which many people have with JWT is that is not strict enough and does not define certain things. PAST uses the same idea, but does not allow that wide variety of different algorithms we could use with JWT. In my eyes it makes it easier to use, because you do not have to search for implementations with compatible and secure algorithms but just for implementations using the latest version of PAST.

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

#88

Post by lvh »

WorldMaker wrote: post #80
lvh wrote: post #61

Earlier quoted context omitted.

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.

Or stateless verification when "other people" are allowed to create claims. There are certainly federation scenarios where PKI alone could be sufficient (as opposed to complex handshakes such as OpenID Connect or SAML). Obviously in accepting those claims you get to treat every claim with a giant grain of salt, but there are auth models where that makes sense (the only claim I need to trust is the certificate itself…

I’m not sure I follow: if the other party is allowed to create claims too, symmetric crypto seems more obvious. That’s what NS (and later KRBv5) did in the seventies. Or is that precisely what you’re saying?

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

#89

Post by k__ »

I had the impression that the main problem was that JWT was marketed as stateless and superior and then you were stuck with stolen tokens.

How does PAST solve this? Is it even possible to get secure stateless auth?

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

#90

Post by duskwuff »

lxe wrote: post #69

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?

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

It does not. Unless you have specifically hardened your server to refuse to even try verifying tokens which use "bad" algorithms, a client can still present a key signed with one of those algorithms, and attempting to verify it may pose a risk.

Post reply on HN