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

91–100 of 140 posts

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

#91

Post by WorldMaker »

lvh wrote: post #88
WorldMaker wrote: post #80

Earlier quoted context omitted.

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?

In a stateless, negotiation-less flow where you have no pre-existing relationship with the other party? Isn't that exactly the bootstrap that PKI was built for?

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

#92

Post by lvh »

jcadam wrote: post #85
lvh wrote: post #72

Earlier quoted context omitted.

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…

Sure, sure: I'm not saying you have to go rip anything up right now (unless someone finds a specific vulnerability), but I was trying to eke out what exactly the benefit was :)

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

#93

Post by lawnchair_larry »

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…

This is actually pretty common and I don't think there is a better way to do it. I am surprised you haven't encountered these systems in cloud environments, particularly where multiple organizations (or just untrusted networks) are involved. Or maybe I'm misunderstanding your criticism.

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

#94

Post by andrewaylett »

owenmarshall wrote: post #37
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.

So I trust you completely here - but I lack the crypto chops to understand why that’s the case, and I’m interested in understanding. Do you have any good recommended primers that’d help me get it? Or should I just get off my arse and finally do cryptopals? ;-)

Having started it but to my shame never managed to finish -- children having got in the way -- I wholeheartedly recommend the latter approach.

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

#95

Post by pinguinFromY »

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 blacklist your tokens in a cache and that's all.

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

#96

Post by lvh »

WorldMaker wrote: post #91
lvh wrote: post #88

Earlier quoted context omitted.

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?

In a stateless, negotiation-less flow where you have no pre-existing relationship with the other party? Isn't that exactly the bootstrap that PKI was built for?

Aha, I missed the stateless negotiation-less flow. But yes, that's basically TLS as deployed in browsers :)

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

#97

Post by zeveb »

lvh wrote: post #26
zeveb wrote: post #18

Earlier quoted context omitted.

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

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

From Jeff Dean's list of numbers every programmer should know[0], a round trip within the same datacenter takes on the order of 500,000 ns; a main memory reference is on the order of 100 ns. How often will an application be making an order of magnitude more than 5,000 main memory references to service a request? Sometimes, sure.

In our experience online validation completely dominates our workloads.

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

Oh, you're completely correct. It has upsides & downsides.

> Without revocation, you can't log out of things, and you can't invalidate sessions after credential rotation.

I pointed out that I like the use of stateless tokens, which can be revoked. In many cases 'log out' can just be destruction of the token. And in many cases it doesn't make sense to invalidate access just because credentials have rotated (in many more cases it does, which of course is perfectly supportable with stateless tokens).

> So unless you're saying tokens should be valid for some tiny number of seconds.

I'm not: I'm saying that in many cases there's no business need to assure revocation within $SMALLNUM seconds, and that the business costs of online validation utterly dominate the costs of running a service.

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

There are only two hard things in computer science … cache invalidation is one of them.

[1] https://gist.github.com/jboner/2841832

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

#98

Post by CiPHPerCoder »

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…

On that note: https://github.com/paragonie/past/issues/13

I might be dropping "seal" entirely, as its utility isn't really a good fit for security tokens. (Sealing APIs can be very useful in other contexts, though.)

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

#99

Post by timwis »

A common security issue I've seen with uses of JWT doesn't have to do with JWT itself but how it's used by front-end developers. It's commonly stored in localStorage instead of an HttpOnly cookie, which creates a cross-site scripting vulnerability.

More details here: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...

Shockingly, the advice I've seen to protect against this by folks like Auth0 is "keep your tokens expiration low" or not mention it at all.

I don't imagine PAST gets around this, as it's more like misinformation around the storage mechanism, but I think it's worth mentioning in any "how to use" section about PAST or JWT.

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

#100

Post by lvh »

zeveb wrote: post #97
lvh wrote: post #26

Earlier quoted context omitted.

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

> In general, asking a database for set membership is not close to the slowest thing applications do. From Jeff Dean's list of numbers every programmer should know[0], a round trip within the same datacenter takes on the order of 500,000 ns; a main memory reference is on the order of 100 ns. How often will an application be making an order of magnitude more than 5,000 main memory references to service a request? Some…

> There are only two hard things in computer science … cache invalidation is one of them.

I mean, it's a pithy saying, but TTL invalidation is a problem you have to solve with JWT too. Caching tokens is the easiest possible cache invalidation problem: definitionally, you know a priori exactly when the token is invalid.

Post reply on HN