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

41–50 of 140 posts

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

#41

Post by WhitneyLand »

atonse wrote: post #13
lvh wrote: post #11

Earlier quoted context omitted.

I haven't reviewed said library, so I'm taking your word for it that it's actually limited to that suite :-) The problems with JWT are more complicated than just negotiation, but you should be OK here. Here's why: - Some bugs are about negotiation, e.g. key material misuse between RSA and HMAC schemes. They don't affect you, because you don't negotiate. - Some bugs are about cryptographic implementation, such as not…

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…

Guys, let me compliment you on some nice work here. Maybe there's still a little spit and polish needed, but the important point is it moves the ball forward.

Sometimes there's so much passion here around implementing cool new things that, while those things are important, it can make it easier to forget that simplicity, and better outcomes on average, are not in any way lesser technical advancements. Simplicity also requires good taste to boot imo.

On a side note from one of your posts, doesn't it make you chuckle a little to think "If you've already decided to implement Javascript Object Signing and Encryption (JOSE), whether you want JSON Web Tokens, JSON Web Encryption (JWE), or JSON Web Signatures (JWS), you should question this decision. You're probably making a mistake.", given the massive growth they've seen over 2-3 years in some very high profile cloud systems? But what to do...onward and upward then. :)

Finally I appreciate the dispassionate viewpoints, i.e. "I'm not attached to it in some way (I never am, to technical decisions)". Always to pleasure to work on hard problems and debate with folks who have adopted that perspective.

Anyway, well done.

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

#43

Post by saganus »

lvh wrote: post #28
saganus wrote: post #19

Earlier quoted context omitted.

What is a use case for minting tokens and one for not minting? I've seen this referenced a few times before but I don't understand why minting tokens is bad. Also, isn't creating a random key as a token the same as minting one? or what is the correct context here for "minting tokens"? Thanks!

When I say "minting a token", I mean taking some data (e.g. your user name), adding some metadata (audience, expiry), and performing some operation on it (signing, encryption, authenticating) such that a different party will accept it as-is. (This is like "minting" because if you have a plausible-looking coin people would just accept it without having to go ask the issuer if it's a real coin via serial number or what…

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 or vice versa, but in general is chaining HMACS still considered "drastically more complicated"?

My uninformed opinion is that verifying a hash shouldn't be that bad but my security expertise is pretty much non-existent so it would be great to be schooled on this :)

[0] - https://research.google.com/pubs/pub41892.html

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

#44

Post by snomad »

lvh wrote: post #11
atonse wrote: post #7

I have implemented JWT on my app but the library I used (Guardian, written in Elixir), only allows you to use HMAC-SHA512 by default. And I've left it that way. Should I still be worried? I get that JWT's algorithm flexibility is overall a bad thing, but if I only allow one, should I continue to worry?

I haven't reviewed said library, so I'm taking your word for it that it's actually limited to that suite :-) The problems with JWT are more complicated than just negotiation, but you should be OK here. Here's why: - Some bugs are about negotiation, e.g. key material misuse between RSA and HMAC schemes. They don't affect you, because you don't negotiate. - Some bugs are about cryptographic implementation, such as not…

May I just point out that Microsoft in ASP Net core is really pushing everyone to JWT (for web api / spa anyways).

I am just trying to build apps, I could care less what protocol is in use, as long as it protects the users. Over the last few days of research (including coming across this HN thread https://news.ycombinator.com/item?id=13865459 from a few months ago) I can't help but feel a) trapped into using JWT and b) that is probably the wrong thing to use and I am going to regret it.

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

#45

Post by giaour »

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…

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 Cognito are verified. They are RS256 JWTs signed with Cognito's private key, and any server can download Cognito's public key to validate that the tokens were issued by Cognito and haven't been subsequently altered (without having to make a network call to Cognito to request validation).

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

#46

Post by lvh »

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…

Sort-of, but not necessarily. It's a lot easier to get the format right if you know there's an authenticator and you know what length it is and it's totally separate from whatever is coming next -- so you still want clear, out-of-band signaling for the real data. Once you have that format, you're right that the exact serialization doesn't matter.

The extreme example of this is XML DSIG and XML canonicalization in general.

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

#47

Post by idbehold »

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.

Versioned Protocol Security Tokens: VPST

Novice-Proof Security Tokens: NPST

Just Verify Valid Tokens: JVVT

Safer Security Tokens: SST

Note: the first one is my only real suggestion, the rest are just for fun. And you are right, it is surprisingly difficult to come up with a good name.

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

#48

Post by lvh »

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

What does it being stateless buy you?

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

#49

Post by lvh »

saganus wrote: post #43
lvh wrote: post #28

Earlier quoted context omitted.

When I say "minting a token", I mean taking some data (e.g. your user name), adding some metadata (audience, expiry), and performing some operation on it (signing, encryption, authenticating) such that a different party will accept it as-is. (This is like "minting" because if you have a plausible-looking coin people would just accept it without having to go ask the issuer if it's a real coin via serial number or what…

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…

If you're going to mint a token, macaroons are a great spec. But when designing a critical security system, the default should be the simplest possible thing, and DB lookup is still much simpler than macaroons. So, you have to have a big problem that macaroons solve first. In my experience, the cure is worse than the disease here.
Post reply on HN