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

191–200 of 304 posts

Re: JSON Web Tokens should be avoided

#191

Post by unscaled »

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…

I did wrap JWT/JWE with a library lest somebody else in my company would get the bad idea to implement directly, and yes, the first thing I've done was to limit the signing algorithm to a single specified algorithm (HS256 for everything that doesn't have to cross service boundaries).

But I admit never thought of it as a particularly bad crypto protocol. It's actually pretty good compared to most negotiable crypto standards out there. I mean, yeah, JWK allows you to embed X.509 (but you don't have to do it), the value of supporting RSA is questionable, their selection of curves is regrettable (but all the world went with the NIST curves), compression on JWE (and not JWS?!) makes me suspicious, and yeah, JSON is kinda verbose compared to MsgPack et al.

But then I remember that before that before JWT came SAML+XML-DSIG (and the whole WS-* ecosystem) and CMS/PKCS#7 (and the whole ASN.1 ecosystem). Ah, compared to these JOSE is a fresh breath of air.

What a lightweight and uncomplicated serialization format - It couldn't even be used for amplified DDOS attacks!

What a modern set of ciphers (besides 'none', sorry, missed that on there ;). No more DES, RC4, or unpopular untested ciphers just there to fill the slots.

Yeah, JOSE still has some parts which are over-engineered but for a STANDARD it's the best one there. Management demands standards, it's a fact of life. And I'd choose JWT over SAML or CMS any day.

Re: JSON Web Tokens should be avoided

#192

Post by stephenr »

homakov wrote: post #8

JWT is bad, signed tokens are fine. Session cookies suck and don't scale. Just copy code of MessageVerifier from Rails, it's simple.

> Session cookies suck

Well that's got me convinced, compelling argument old chap.

> and don't scale.

The vast majority of developers in the world are never going to actually need the type of scalability that requires stateless tokens for authentication.

Re: JSON Web Tokens should be avoided

#193

Post by striking »

nocman wrote: post #153
jv22222 wrote: post #152

Earlier quoted context omitted.

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

You should write a browser extension that fixes that. I'd use it.

Re: JSON Web Tokens should be avoided

#194

Post by cptskippy »

Klathmon wrote: post #129
cptskippy wrote: post #123

Earlier quoted context omitted.

Definitely, there's a whole host of potential pitfalls from assigning cookies to the TLD. From the OP's post though it sounded like their issue was one subdomain being unable to access cookies of another subdomain.

It's more issues with "3rd party" cookies. "app.hostname.tld" doesn't need to actually access the cookies at all, it just needs to make requests to "api.hostname.tld" which sets the cookies and then later validates them. Unfortunately safari blocks this use case unless you have also been to "api.hostname.tld" directly and there doesn't seen to be any easy way around it (outside of allowing all 3rd party cookies...) A…

Ahh... yes I'm familiar. I've worked on a couple apps where Apple/Mozilla 3rd Party Cookie polices were a pain point. One option we used was an interstitial page that the user visited briefly hosted on the API layer. Another was switching from cookies to Bearer Tokens which is a whole other bag of worms.

Re: JSON Web Tokens should be avoided

#195

Post by tptacek »

unscaled wrote: post #191
tptacek wrote: post #86

Earlier quoted context omitted.

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…

I did wrap JWT/JWE with a library lest somebody else in my company would get the bad idea to implement directly, and yes, the first thing I've done was to limit the signing algorithm to a single specified algorithm (HS256 for everything that doesn't have to cross service boundaries). But I admit never thought of it as a particularly bad crypto protocol. It's actually pretty good compared to most negotiable crypto sta…

"Better than XML-DSIG" is not a reasonable bar. Your description of the protocol is as damning as mine is.

Re: JSON Web Tokens should be avoided

#196

Post by mwpmaybe »

deathanatos wrote: post #173
Illniyar wrote: post #110

Earlier quoted context omitted.

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)

The downside being that the browser will attach it to every request; if you use cookies, you MUST be aware of this, or you are (IMO) pretty much guaranteed to write a CSRF vuln. (I'm much more in the localStorage + Authorization header for this reason. I recommend [1] for reading. If malicious JS is running, cookies won't save you, since the malicious JS is capable of simply making the request itself, to which the co…

CSRF protection:

* Use SameSite cookies (unfortunately, not yet supported by all browsers)

* Don't accept application/x-www-form-urlencoded, multipart/form-data, or text/plain at your endpoints, or

* Use CSRF tokens if you need to accept server-side rendered HTML forms

Re: JSON Web Tokens should be avoided

#197

Post by lpa22 »

throwaway2016a wrote: post #131
scandox wrote: post #47

I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). Probably I can achieve the same overall system with cryptographically secure session cookies, that are persisted in a database, or other store that is accessible across multiple servers. I guess it wo…

> So overall while I don't know how right he is, I feel like maybe he has a point. Why not just use cookies? Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks. A cookie that requires you to hit the database does not solve that issue. Although if the cookie was signed some way that can be cryptographically verified then great. But then you are essen…

I think the expense of validating authorization to a database can often be worth the cost. Having a dedicated sharded SSD DB system, or other fast cached DB system that is dedicated to checking and validating a cookie/token of a user for each request solves many problems, such as quickly clearing tokens in the case of a hack, and if there is a DB failure on one of these systems then the user simply has to login again and their token/cookie will be stored on another DB in the shard.

The extra overhead on each request of checking these credentials, especially when these requests are hitting the product's database anyway, are often worth the additional security.

Re: JSON Web Tokens should be avoided

#198

Post by unscaled »

falcolas wrote: post #95
meddlepal wrote: post #90

Earlier quoted context omitted.

I feel like the argument against #2 is usually purely hypothetical in nature. I really do not have a problem maintaining a small lookup cache for revocations. I feel like the argument against doing this tries to take the form of all server-side kept state is bad when in reality it's sticky state and huge object graphs (read: memory consumption) that get stuffed into session objects that are the real evil. A server wi…

Sure, revocation lists are relatively small. But they need to be available to every server (replication), be proof against server/service restarts (durable), and checked with every request (highly performant). So, a good revocation list effectively requires a database. Not a trivial thing to implement yourself, and a weighty requirement for an otherwise stateless service.

JWT are even smaller than their size since you can revoke them by hash (although you should really just revoke by user ID in most cases).

Your tokens should generally have a rather short lifetime - then you can keep the entire relevant window of revocations in memory.

The implementation is not trivial though, that's for sure.

Re: JSON Web Tokens should be avoided

#199

Post by nocman »

striking wrote: post #193
nocman wrote: post #153

Earlier quoted context omitted.

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

You should write a browser extension that fixes that. I'd use it.

Ooh, I like that idea. Don't tempt me!

xD

Re: JSON Web Tokens should be avoided

#200

Post by kgilpin »

If you are interested in a Ruby library for signing and verifying a token containing a simple payload, take a look at our Slosilo library:

https://github.com/conjurinc/slosilo#signing

We use this library to store a signed username. Nothing more than that, just a username in a signed, expiring token. No `alg` field or any other options.

The Slosilo code has been subjected to a professional crytographic audit, so it's safe for you to use. Unfortunately, without an NDA, we can't show you the audit report, that's just how these things work. The only audit finding was a recommendation that we switch to `AES-256-GCM`, which we did in Slosilo 2.0, November 2014.

Post reply on HN