Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens should be avoided

paragonie.com

Post reply on HN
Print view View original

151–160 of 304 posts

Re: JSON Web Tokens should be avoided

#151

Post by davewritescode »

tptacek wrote: post #86
asanso wrote: post #78

The author of http://blog.intothesymmetry.com/2017/03/critical-vulnerabili... here FWIW. Personally I would not be so drastic. JOSE per se is not too bad (at least the idea is cool). Some crypto choices though have been really arguable...

That post is great work. Thanks again. But I think you're wrong about JWT. The problem with JWT/JOSE is that it's too complicated for what it does. It's a meta-standard capturing basically all of cryptography which, as you've ably observed (along with Matthew Green), was not written by or with cryptographers. Crypto vulnerabilities usually occur in the joinery of a protocol. JWT was written to maximize the amount of…

JWT begs you to use public key because it makes sense for a lot of the use cases that people implement using JWT specifically having a single token issuer while having distributed token validation.

Using a public key algorithms makes also it easier to implement a sane key rollover strategy. I suspect this is the reason that Auth0 pushes their customers to validate tokens with public keys published on their JWKS endpoints.

As for X.509, I agree it kind of sucks but what are the alternatives?

Re: JSON Web Tokens should be avoided

#152

Post by jv22222 »

StevePerkins wrote: post #70

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…

On another note.

Dear Americans, the queen would like you to stop saying "could care less" - by David Mitchell of Peep Show

https://www.youtube.com/watch?v=om7O0MFkmpw

Re: JSON Web Tokens should be avoided

#153

Post by nocman »

jv22222 wrote: post #152
StevePerkins wrote: post #70

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…

On another note. Dear Americans, the queen would like you to stop saying "could care less" - by David Mitchell of Peep Show https://www.youtube.com/watch?v=om7O0MFkmpw

I am American, and I'm sure this bothers me more than it actually bothers the queen.

Between that and the incessant use of the incorrect phrase "for free" instead of the correct phrase "for nothing" it's amazing that I can stand to read anything on the internet.

xD

Re: JSON Web Tokens should be avoided

#154

Post by jchrisa »

tptacek wrote: post #86
asanso wrote: post #78

The author of http://blog.intothesymmetry.com/2017/03/critical-vulnerabili... here FWIW. Personally I would not be so drastic. JOSE per se is not too bad (at least the idea is cool). Some crypto choices though have been really arguable...

That post is great work. Thanks again. But I think you're wrong about JWT. The problem with JWT/JOSE is that it's too complicated for what it does. It's a meta-standard capturing basically all of cryptography which, as you've ably observed (along with Matthew Green), was not written by or with cryptographers. Crypto vulnerabilities usually occur in the joinery of a protocol. JWT was written to maximize the amount of…

You are making the same mistake the IndexedDB haters made. The standardization effort around JOSE, as far as I can tell, is about making the browser a place where you can run crypto. They want it to be composable because that's the web way.

I can agree with your critiques but still wish "real" cryptographers would accept the inevitability of a worse-is-better approach winning here. Don't flip tables, write the jQuery of web crypto. You'll do more good in the long run going with the flow on this one.

Re: JSON Web Tokens should be avoided

#155

Post by arethuza »

fovc wrote: post #97
tptacek wrote: post #77

Earlier quoted context omitted.

I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, yo…

It's not that need an RFC standardized solution for everything, but I'd rather not roll my own anything related to crypto. Would something like crypto_auth(json(bag)) be better here? (crypto_auth from libsodium, json being sorted without whitespace)

"json being sorted without whitespace"

What is the significance of that part?

Re: JSON Web Tokens should be avoided

#156

Post by zeveb »

I think that JSON Web Tokens (like most things involving JSON) are ill-thought-out, and they can definitely be a bit of a foot-gun, but they are also useful.

I do take issue with the idea that they're not good for stateless authentication: I think they're great when used as short-lived authentication tokens (which don't require serve state) with accompanying long-lived refresh tokens (which do require server state). E.g. a system in which auth tokens are good for an hour and refresh tokens are good for longer (and a refresh token can be refreshed) offer a pleasing user experience (in the normal case, one need never log back on) while also preserving security (revocation takes at most an hour to come into effect). The business gets to make the economic decision about the tradeoffs between risk and cost, deciding whether auth tokens should last for a day, an hour, a minute or a second. I don't think this is 'congratulations, you've reinvented stateful sessions'; rather, it's a well-designed system.

I do wish that JWTs had been better designed, and I wish that folks didn't have to be so careful using the libraries which support them.

Re: JSON Web Tokens should be avoided

#157

Post by jdmichal »

jchw wrote: post #147
StevePerkins wrote: post #70

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…

What's difficult about setting up a Redis cluster to back sessions? Yes, it adds a point of failure... so does having a database of any kind. However, I'd hardly call it difficult. If you're on Amazon, you can just create an Elasticache cluster and not even concern yourself with the ops. I don't hate secure cookies or anything, but some people act like plain-old regular cookies haven't been thoroughly solved by this…

Nothing's difficult about that. But that doesn't mean that it's a good idea. How about distributing a signature and encryption key to all your servers, and using them to secure the outgoing and verify the incoming tokens. If you want easy, that's probably even easier than setting up a Redis store and tying your services to it.

Need an emergency revoke of every token? Easy: Replace your signature key. Any older token will fail signature verification. In which case, your system should require authentication and then generate a new token with an updated signature.

Re: JSON Web Tokens should be avoided

#158

Post by eric_the_read »

jv22222 wrote: post #152
StevePerkins wrote: post #70

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…

On another note. Dear Americans, the queen would like you to stop saying "could care less" - by David Mitchell of Peep Show https://www.youtube.com/watch?v=om7O0MFkmpw

I could care less about this request, but I can't be bothered to make the effort.

Re: JSON Web Tokens should be avoided

#159

Post by zeveb »

arethuza wrote: post #155
fovc wrote: post #97

Earlier quoted context omitted.

It's not that need an RFC standardized solution for everything, but I'd rather not roll my own anything related to crypto. Would something like crypto_auth(json(bag)) be better here? (crypto_auth from libsodium, json being sorted without whitespace)

"json being sorted without whitespace" What is the significance of that part?

It makes JSON deterministic, which it isn't by default (e.g. {"foo": 1, "bar": 2} and {"bar":2,"foo":1} are both valid serialisations.

Of course, it'd be better still to use a format _meant_ to provide human-readable canonical representations of data, e.g. Ron Rivest's canonical S-expressions (http://people.csail.mit.edu/rivest/Sexp.txt), but of course this is information technology and we have to reinvent the wheel — usually as an irregular polygon — every 3-4 years rather than using techniques which are tried and true.

Re: JSON Web Tokens should be avoided

#160

Post by zeveb »

Illniyar wrote: post #110
meric wrote: post #103

Earlier quoted context omitted.

I hope someone can explain to me in practical terms difference between a session cookie string on a request and a token as header value.

Cookies are just string in a header. The difference is that unlike normal headers browesers treat cookie headers in a special way. They automatically add and remove keys from it, and they allow the server to set the header in a way that the client can neither see it nor change it (http only headers)

One small correction: the client (i.e., the web browser or other web client) can see HTTP-only cookies just fine; code running in a conforming browser cannot.

But if I write some code using DRAKMA, urllib or net/http, and can see those cookies just fine.

Post reply on HN