JSON Web Tokens should be avoided • Hacker News Board

Re: JSON Web Tokens should be avoided

#171

Post by ash » Tue, Mar 14, 2017, 3:41 PM UTC

tlrobinson wrote: post #138

For my current use-case, one of the appealing things about JWT is there are libraries for just about every language, which makes it easy for 3rd party developers to integrate with my service. Are there any better alternatives to JWT that have implementations in many languages? If not, elsewhere in this thread tptacek and others have suggested essentially `base64_encode(crypto_auth(json_encode(object)))` would be suff…

I was confused about libsodium/NaCl APIs, specifically crypto_sign vs crypto_auth. The difference:

1. `crypto_auth` is for secret-key signatures (auth): https://download.libsodium.org/doc/secret-key_cryptography/s...

2. `crypto_sign` is for public-key signatures: https://download.libsodium.org/doc/public-key_cryptography/p...

And tptacek is arguing secret (symmetric) key is preferable: https://news.ycombinator.com/item?id=13866983

Re: JSON Web Tokens should be avoided

#172

Post by jdmichal » Tue, Mar 14, 2017, 3:43 PM UTC

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…

I can make an attempt at an alternative:

Distribute signing and encryption keys to all servers. Have them encrypt and sign the outgoing serialized token, whatever that consists of. Have them verify and decrypt the incoming token. This is just straight-forward cryptography, with keys known only to the server, so I'm pretty sure you won't get any arguments from (1). (And, I suppose the encryption could even be skipped, if you don't care that the internal format of the token is known.)

Emergency revocation of all tokens [0] is simply rotating the signing key. All tokens issued prior to the rotation will fail verification with the new key. That should trigger the authentication process, which will issue a new token with the updated key. This solves the revocation issue present in argument (2).

[0] Any other form of revocation is, in my opinion, not distinguishable from having server-side state. If you have to keep a list of bad tokens, why not just keep a list of the good tokens instead... And then it's only a short hop to the token being nothing but a key to lookup the full session state on the server.

Re: JSON Web Tokens should be avoided

#173

Post by deathanatos » Tue, Mar 14, 2017, 3:43 PM UTC

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)

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 cookie will automatically be attached by the browser. localStorage+JS eliminates CSRF. If someone XSS's you, the difference is irrelevant.)

[1]: http://blog.portswigger.net/2016/05/web-storage-lesser-evil-...

Re: JSON Web Tokens should be avoided

#174

Post by alejogutierrez » Tue, Mar 14, 2017, 3:44 PM UTC

This is my opinion about the article:

1. Yes looks like the author is criticizing some implementations libraries: The solution is look carefully to choose your lib. And the advice for every library is to not allow weak encryption algos and off course "none" as an option. This is the kind of problem of services still using md5 to store passwords.

2. The JWT standard is simple and like the other standards has pitfalls but still usable: I think the author comes along with the use instead in some way of promoting libsodium crypto lib, well fine but the thing is to explain the alternatives in the particular case. So sessions are good for webapps the kind of Rails, Laravel etc, but what is the path when you need independent services? Then you have OAuth1, OAuth2 and JWT, which again every case has it's own purposes. Someone said that JWT are difficult. Really? I don't think so, in OAuth you need to understand very well the grant types to choose the appropriate. Also the reference of "Stop using JWT for sessions" is bad I think. First everybody knows that blacklists are bad is preferable to use simple whitelist, then problem with your server, hey no matter what implementation you use if your server is down you service is down.

So to abbreviate the problem itself is about the libs and the lack of implementation information on the spec, but I don't think is that bad standard.

Re: JSON Web Tokens should be avoided

#175

Post by joepie91_ » Tue, Mar 14, 2017, 3:47 PM UTC

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…

> I'm much more in the localStorage + Authorization header for this reason.

That's just exchanging one security issue for another. Now you have the ability for people to steal tokens after an XSS attack. And yes, that's significantly different from "can make requests on your behalf".

The correct solution is to solve the CSRF vulnerabilities by using CSRF tokens. Not to change your auth persistence mechanism.

Re: JSON Web Tokens should be avoided

#176

Post by unscaled » Tue, Mar 14, 2017, 3:48 PM UTC

davewritescode wrote: post #151

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…

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

The alternative is pushing plain public keys over an authenticated channel. You usually don't need the complexity of X.509.

That being said, the aforementioned authenticated channel will more often than not be TLS, which does happen to rely on X.509.

Re: JSON Web Tokens should be avoided

#177

Post by joepie91_ » Tue, Mar 14, 2017, 3:50 PM UTC

Klathmon wrote: post #49

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…

If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not witho…

These "annoyances" are security features. They're there for a reason. Learn how they work and why they exist. Use them. Stop trying to treat them as bugs that you need to work around.

Re: JSON Web Tokens should be avoided

#178

Post by jdmichal » Tue, Mar 14, 2017, 3:53 PM UTC

jayd16 wrote: post #167

lr4444lr wrote: post #121

Earlier quoted context omitted.

I just can't reconcile the fact that if I hit an endpoint, and I get back certain data with a 2XX response code because I previously accessed a "login" resource, but I would have gotten a 4XX response code if I had not gone to that prior "login" resource that I haven't violated REST: my request for the second endpoint takes advantage of stored context on the server. Even worse, if I restart the server, change out its…

Rest doesn't mean no state in the world exists. It's not a violation at all that an endpoint changes its output. Rest only reasons about idempotency, not reproducibility.

> Rest only reasons about idempotency, not reproducibility.

Absolutely. If you GET a collection resource, then POST a new item into the collection, then GET the collection again, the response will have changed. Having these kind of temporal dependencies on the answer you receive is not something REST argues against.

Re: JSON Web Tokens should be avoided

#179

Post by mwpmaybe » Tue, Mar 14, 2017, 3:54 PM UTC

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.

* MessageVerifier defaults to SHA1. That hasn't been a good default for a few years now.

* It doesn't support expiry as a claim; you have to check it against the current time manually, and factor in leeway if you want that. Because no one ever screwed up a timestamp check.

* It doesn't support any other verifiable claims, for that matter, so if you want to add e.g. issuer and issued-at, you'll have to do so manually.

* If you're not writing a Rails app, you have to pull in ActiveSupport... or copy code, as you suggest, which seems bad for other reasons. Surely maintaining your own crypto fork is almost as bad as writing your own crypto in the first place?

* To the best of my knowledge, ruby-jwt has not suffered either of the two JWT vulnerabilities discussed in this thread.

Finally, why is this "simple":

    @verifier = ActiveSupport::MessageVerifier.new('s3Krit', digest: 'SHA256')

    cookies[:remember_me] = @verifier.generate([@user.id, 2.weeks.from_now])

But this is "bad":

    payload = { sub: @user.id, exp: Time.now.to_i + 1_209_600 }

    cookies[:remember_me] = JWT.encode(payload, 's3Krit', 'HS256')

They seem fairly equivalent to me?

Re: JSON Web Tokens should be avoided

#180

Post by tptacek » Tue, Mar 14, 2017, 3:54 PM UTC

danjoc wrote: post #161

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…

>that rebuts the (I think sort of silly) presumption that whatever an app uses needs to be RFC standardized. I thought crypto mantra was "Never roll your own." An RFC (Request For Comments) is a literal attempt to follow that advice by seeking the advice of cryptographers who are presumably smarter at coming up with crypto standards. Where were the cryptographers during the draft phase when comments were being solici…

I don't care about these moral arguments. I'm making a simple, positive claim: JWT is bad. You can blame whoever you'd like for it being bad, but as engineers, you need to understand first and foremost that JWT is bad, and reckon with your feelings about that later.

You have a responsibility to built trustworthy systems, and you get no pass on building with flawed components simply because you wish experts had made those components less flawed.