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

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

#21

Post by atonse » Thu, Jan 04, 2018, 3:47 PM UTC

lvh wrote: post #16

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…

Sorry, I didn't mean to come across as bitey. It's just that almost everyone I've talked to who has made this decision and lived with it for over a year has come to the same conclusion: just use a random key and store it in a database :)

Yeah no worries. I sort of agree with you. I don't have any strong opinions on why I chose it apart from that it was easy to implement.

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

#22

Post by tptacek » Thu, Jan 04, 2018, 3:51 PM UTC

eadmund wrote: post #9

tptacek wrote: post #4

This is better than JWT. In particular: the whole protocol is versioned, rather than serving as a metaprotocol that negotiates the underlying cryptography. If you speak "v2" of this protocol, and refuse to accept any other version, then you're getting a token that is basically just Nacl. My only nit --- apart from the "auth enc seal sign" names, which aren't coherent --- is why do public key at all? Yes, Nacl support…

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 cryptography that happens when people find new reasons to deploy public key primitives.

Note that one of the first crypto bugs in JWT stemmed from how it used curve public key crypto.

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

#23

Post by jcadam » Thu, Jan 04, 2018, 3:54 PM UTC

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…

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

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

#24

Post by grogenaut » Thu, Jan 04, 2018, 4:04 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…

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 out the opportunity to educate instead of just say things are bad).

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

#25

Post by grogenaut » Thu, Jan 04, 2018, 4:07 PM UTC

lvh wrote: post #15

tootie wrote: post #14

I don't get it. We used to use something like a pipe-delimited string, then JWT, now PAST. Isn't the encryption doing all the work regardless of how the data is structured?

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 anything else. As you said that's just serialization.

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

#26

Post by lvh » Thu, Jan 04, 2018, 4:08 PM UTC

zeveb wrote: post #18

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

> you probably still just want a random key in a database. In general, I think that this is the wrong approach, because that means adding a database round-trip (which in a large system is almost certainly a network round-trip) for each and every API call. Notably, if the entire system is secured in depth (which large systems should be), it means adding a network round-trip for every layer of the API (e.g. one for the…

> In general, I think that this is the wrong approach, because that means adding a database round-trip (which in a large system is almost certainly a network round-trip) for each and every API call.

In general, asking a database for set membership is not close to the slowest thing applications do.

> Notably, if the entire system is secured in depth (which large systems should be), it means adding a network round-trip for every layer of the API (e.g. one for the frontend server to validate the user, then another for a backend server to validate the frontend server). Using a stateful token[0] replaces that network round trip with a public-key or hash verification, which is much faster.

A handful of those set membership checks: still not the slowest thing applications do. (Also, I don't think it's a given that internal auth has to work the same way external auth does, for a bunch of reasons.)

> I think that generally revocation concerns are a bit overblown.

Without revocation, you can't log out of things, and you can't invalidate sessions after credential rotation. So unless you're saying tokens should be valid for some tiny number of seconds... in which case, it's questionable that you're buying a lot of performance for your drastically more complicated token scheme.

> Even with a database lookup on every request, there is a (small) amount of time that one is willing to act on out-of-date information (after all, the user's access could be disabled immediately after the lookup, before the action is performed). Almost every business has some window in which it is willing to act on old information: better to make it explicit than to leave it implicit.

Median response time is not comparable to usual token expiry times. If you do make them comparable, then you're making that DB check every time anyway. The entire point of the token is to do that less. You're right that it's implicit, but it's also "the fastest that it possibly ever could be", so that's not a bad kind of implicit.

If you really desperately want to make the check faster, why is JWT better than a local token cache?

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

#27

Post by rocky1138 » Thu, Jan 04, 2018, 4:11 PM UTC

lvh wrote: post #16

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…

Sorry, I didn't mean to come across as bitey. It's just that almost everyone I've talked to who has made this decision and lived with it for over a year has come to the same conclusion: just use a random key and store it in a database :)

Simpler is almost always better.

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

#28

Post by lvh » Thu, Jan 04, 2018, 4:12 PM UTC

saganus wrote: post #19

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

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

When you generate a random key, you have to go ask a trusted third party what the data associated with that key is (and, therefore, if it's still valid).

Minting tokens is bad because it's drastically more complicated, has tons of failure modes, and most of the time you end up doing tons more database transactions anyway that are way more complicated than set membership (i.e. is this still a valid token?).

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

#29

Post by tptacek » Thu, Jan 04, 2018, 4:14 PM UTC

grogenaut wrote: post #24

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…

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.

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

#30

Post by idbehold » Thu, Jan 04, 2018, 4:16 PM UTC

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