Show HN: PAST, a secure alternative to JWT • Hacker News Board

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

#51

Post by saganus » Thu, Jan 04, 2018, 5:12 PM UTC

lvh wrote: post #49

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…

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.

Thanks a lot for the insight.

It's amazing how seemingly simple things can get so complicated when talking about security.

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

#52

Post by allyant » Thu, Jan 04, 2018, 5:13 PM UTC

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 fully weakened and OpenResty + Redis can be relatively fast.

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

#53

Post by WhitneyLand » Thu, Jan 04, 2018, 5:22 PM UTC

grogenaut wrote: post #31

tptacek wrote: post #29

Earlier quoted context omitted.

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.

My speculative interpretation (which Thomas may disavow completely) is that not that eadmund was doing something technically broken, as much as adding complexity, and risk of mistakes somewhere along the chain, without benefits to justify doing so.

If you listen closely, some security wisdom could applies to a lot of specialties. For ex this quote is about authenticated encryption, but it's not really bad advice if you change the subject from encryption, to rolling your own web server:

"Authenticated encryption is something you should use as a complete package, implemented as a single unit by a well-reputed open source cryptographic library and not assembled piecemeal by people who do not specialize in cryptography."

So what's the difference then? The stakes are higher. Serve the wrong web page, you'll be working on a bug. Be careless with security primitives, you could make a fortune 500 stock price go down, or make your CEO have to issue a press release, which tends to not to reflect well on your performance review.

In this light, "finding new reasons" I would infer to mean deviating from established best practices in any way without a damn good reason, even then without that reason being challenged and vetted.

All of the creativity in security should be in the research. For production implementations I don't want any creativity. Ideally, I'd want prod to be the opposite of research: Conservative and uncreative, struggling to stay awake because it's so boring and uneventful.

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

#54

Post by jcadam » Thu, Jan 04, 2018, 5:24 PM UTC

lvh wrote: post #48

jcadam wrote: post #23

Earlier quoted context omitted.

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?

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.

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

#55

Post by davewritescode » Thu, Jan 04, 2018, 5:36 PM UTC

giaour wrote: post #45

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…

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

Was just going to post this, JWT with public keys is very handy for stateless verification of claims, which is what it seems was the primary motivator of the spec.

As someone who had to work with XML-DSIG, JWT seems less bad :)

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

#56

Post by grogenaut » Thu, Jan 04, 2018, 5:38 PM UTC

WhitneyLand wrote: post #53

grogenaut wrote: post #31

Earlier quoted context omitted.

I'd still love to know the details.

My speculative interpretation (which Thomas may disavow completely) is that not that eadmund was doing something technically broken, as much as adding complexity, and risk of mistakes somewhere along the chain, without benefits to justify doing so. If you listen closely, some security wisdom could applies to a lot of specialties. For ex this quote is about authenticated encryption, but it's not really bad advice if y…

Sure, I get all that, I want the technical details though. Or pointers to where I can learn more. His advice says what not to do but not really what to do or where to learn more.

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

#57

Post by hirsin » Thu, Jan 04, 2018, 5:39 PM UTC

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…

If you're open to questions, I'd be curious for your take on token binding as well, as that seems to be in the same ballpark (or same sport at least).

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

#58

Post by grogenaut » Thu, Jan 04, 2018, 5:40 PM UTC

lvh wrote: post #46

grogenaut wrote: post #25

Earlier quoted context omitted.

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

Agreed, but there's not really something inherently insecure about JSON vs concatted strings vs binary (well readability on that one). It's all about the JWT spec being complicated and easy to mess up.

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

#59

Post by lvh » Thu, Jan 04, 2018, 5:41 PM UTC

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: he's using public key as in public-key cryptography, as opposed to secret-key cryptography.

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

#60

Post by lvh » Thu, Jan 04, 2018, 5:43 PM UTC

giaour wrote: post #45

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…

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

I don't understand the conflation. 'tptacek is arguing that you preferentially use secret-key crypto to public-key crypto, because public-key crypto is significantly more precarious. It seems like you are raising a new point, not arguing with his.