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

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

#71

Post by atmosx » Thu, Jan 04, 2018, 6:12 PM UTC

zimpenfish wrote: post #34

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.

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

Here:

https://storify.com/jcuid/thomas-h-ptacek-don-t-use-json-web...

https://news.ycombinator.com/item?id=13866883

https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/

or go with the flow:

https://www.google.gr/search?q=ptacek+jwt&oq=ptacek+jwt&aqs=...

He has countless comments preaching against JWT and DNSSEC.

Mind you, I know the nickname, I know he is good with sec (I'd hire him to vet an app) and all but I don't know him IRL or ever heard of him before joining HN ... that's to say that he spent a lot of digital ink discussing these two topics here. The subset he's talking about, should amount for more than 50% of the regulars I guess.

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

#72

Post by lvh » Thu, Jan 04, 2018, 6:13 PM UTC

jcadam wrote: post #54

lvh wrote: post #48

Earlier quoted context omitted.

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.

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 situation with no crypto to mess up.

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

#73

Post by treve » Thu, Jan 04, 2018, 6:15 PM UTC

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 think one of the issues is a very practical one. When everything is called JWT, it's hard for users to figure out whether it's a secure or insecure implementation.

It's completely possible to do secure things with JWT, especially if you control every producer and consumer, but it's not guaranteed.

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

#74

Post by kpil » Thu, Jan 04, 2018, 6:16 PM UTC

lvh wrote: post #61

davewritescode wrote: post #55

Earlier quoted context omitted.

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

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.

Public keys solve the key management problem. If you have just one or two tiers it's not a problem.

If you have thousands, you end up spending a lot of time on key distribution if you need individually distributed secret keys.

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

#75

Post by level » Thu, Jan 04, 2018, 6:17 PM UTC

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?

The problem is that it's not idiot-proof. If someone doesn't understand why the algorithm is important, they might choose none. It's easy to say "they shouldn't be using JWTs if they don't know how to use them", but everyone starts somewhere, and everyone puts stupid bugs into production.

JWT is safe, as long as it's setup correctly, but safe-by-default is a better option.

That being said, I'm not going to swap out my JWTs with PASTs. I know what algorithm I'm using, why I'm using it, it is safe, and I'm verifying them properly.

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

#76

Post by lvh » Thu, Jan 04, 2018, 6:18 PM UTC

grogenaut wrote: post #56

WhitneyLand wrote: post #53

Earlier quoted context omitted.

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.

(Hi I'm not 'tptacek, I work with him but don't speak for him)

If you just want a few examples of stuff that can go wrong that doesn't go wrong if you just use a stored token instead of crypto, or doesn't go wrong if at least you use symmetric crypto instead of asymmetric crypto:

- Some bugs are about negotiation, e.g. key material misuse between RSA and HMAC schemes in JWT.

- Some bugs are about cryptographic implementation, such as not reusing nonces for ECDSA or RSA padding oracles or RSA keygen vulns (see Infineon bugs a few months ago). These are almost exclusively in the asymmetric crypto camp.

- Some bugs are about specification issues, such as non-mandatory aud (audience) and exp (expiry). You don't have specification issues if your tokens are opaque random numbers. You have significantly less bad/fewer specification issues if your tokens are versioned and you don't allow negotiation.

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

#77

Post by treve » Thu, Jan 04, 2018, 6:22 PM UTC

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…

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?

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

#78

Post by lvh » Thu, Jan 04, 2018, 6:25 PM UTC

kpil wrote: post #74

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.

Public keys solve the key management problem. If you have just one or two tiers it's not a problem. If you have thousands, you end up spending a lot of time on key distribution if you need individually distributed secret keys.

You say that, but best practice for systems that have that option (say, internal SAML IdPs) still means you do per-peer keys with the annoying key management problem so that you get cryptographic binding instead of relying on a bunch of broken RPs to validate audience restrictions (spoiler: they don't) and in some cases IdPs or middleboxes that need to add audience restrictions (spoiler: they don't either).

What you get is that the peer can't forge tokens. But you're trying to authenticate to them; they already have full authority. So what are you fixing? (I'm not saying it's "nothing", but I am saying it's very little, and it's definitely plausible the increased risk isn't worth it.)

What do you mean by "tiers" here? The specificity of that word suggest you don't just mean "peers", but at the same time clearly symmetric systems win at nested delegation. (krb5, macaroons come to mind)

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

#79

Post by Shoothe » Thu, Jan 04, 2018, 6:31 PM UTC

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…

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 use any system to encode claims). But there is no standard to encode them and that causes tight coupling between systems using Macaroons. I can go into more detail if that's interesting for someone.

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

#80

Post by WorldMaker » Thu, Jan 04, 2018, 6:32 PM UTC

lvh wrote: post #61

davewritescode wrote: post #55

Earlier quoted context omitted.

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

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 scenarios, for example).

That said, very few people want such a security scheme and as theoretically simple as it is on paper, it quickly ramps up to the real world complexity of PKI key management.

(I could see a small use for web APIs for developers and power users that allowed, for instance, Keybase-verified claims like HN account name/FB name/email, for very simple and easy to curl/iwr/httpie from the command line using Keybase-managed keys.)

I'm not sure if that small window of opportunity is worth the support complexity in PAST here, but given the model of support only specific versions, having them as separate verbs (sign/seal) makes it easy to block claims you don't expect. The one flipside from an API design standpoint that I see is that leaves a need for some sort of header like X-Accept-PAST: v2.auth