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

111–120 of 140 posts

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

#111

Post by e12e »

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?

Kerberos vouching hinges on "ticket-granting server says...", and you know that because the tgt shares a secret with every player. On the face of it, it'd be much easier to just demand everyone know the tgt's public key (no need for N keys on the tgt for N participants).

I've long considered the merits of a kerberos-like system built on top of something like nacl... But without out-of-the-box support from all kinds of systems... It'd essentially build down to ssh+certificates with expiration dates... So i've gathered "better CA for ssh" is the better product. And there are thankfully a couple of projects in that vein (teleport, netflix/bless, others?).

[ed: i should add: I think tptacek is absolutely right about public key systems being easier to get wrong; but part of that is also the problem domain: look at the history of security issues with Kerberos (both implementations and protocol evolution) for a great example. On the face of it NxN key exchange is "text book simple; should be easy to define, a little tricky to scale". Then there's replay, clock drift, (de)serialisation, nounces, large number of session keys (secure random numbers)...]

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

#112

Post by zeveb »

lvh wrote: post #78
kpil wrote: post #74

Earlier quoted context omitted.

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…

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

You get something you can show to a third party: 'see, the bank said their client was good for $10,000!' I can see where that might be useful.

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

#113

Post by treve »

CiPHPerCoder wrote: post #86
treve wrote: post #77

Earlier quoted context omitted.

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?

I've written about this at length here: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... (It's also the first link in the README for the project this Show HN is linking to, FWIW)

Those are mostly the drawbacks of JWT, less so using stateless sessions altogether.

I found some additional reasons from a page that was linked from that last link here: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...

  * They take up more space  
  * You cannot invalidate individual JWT tokens
The other reasons seem a bit weaker.

In your opinion, are those also the reasons why you wouldn't use PAST for stateless sessions?

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

#114

Post by wglb »

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? ;-)

I would recommend doing cryptopals in any case. It will give you a good background on this and other crypto topics so you can evaluate for yourself.

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

#115

Post by e12e »

pinguinFromY wrote: post #95
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.

So, for a secure system, the blacklist cache/service becomes a single point of failure (see also certificate revocation lists, ssl/tls).

I personally think renewable, short-lived tickets/tokens are a better evil - accept that a compromised session is valid for 10 minutes (5+worst-case/accepted clock drift).

A long-lived certificate can encode authorization + but needs a short-lived ticket to be valid ("an I'd card that says three star general and today's pass phrase").

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

#116

Post by piotrkubisa »

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.

PINJWT - "PAST is not a JWT". // Please, do not take it seriously.

Edit: Good job on PAST and your other projects. I often follow your GitHub activity and publications to check on what interesting you are working currently.

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

#117

Post by tptacek »

zeveb wrote: post #112
lvh wrote: post #78

Earlier quoted context omitted.

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…

> 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.) You get something you can show to a third party: 'see, the bank said their client was good for $10,000!' I can see where that might be…

This feels like grasping at straws.

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

#118

Post by lvh »

zeveb wrote: post #112
lvh wrote: post #78

Earlier quoted context omitted.

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…

> 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.) You get something you can show to a third party: 'see, the bank said their client was good for $10,000!' I can see where that might be…

I don't think I could've made my own point this elegantly. Eventually trying to disprove what the other party is saying is literally the opposite of what normal token schemes (say, SAML or OIDC JWT) is trying to accomplish: trying to establish what the other party is claiming.

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

#119

Post by lvh »

lvh wrote: post #101
zeveb wrote: post #97

Earlier quoted context omitted.

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

> 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. That argument is only valid if your application doesn't touch disk and doesn't touch th…

Just in case someone else reads this thread later, the point I was going to make:

- DC roundtrip: 0.5ms (per GP's own numbers)

- P256 ECDSA signature validation: 2ms [0]

[0]: https://www.cryptopp.com/benchmarks.html

Post reply on HN