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

201–210 of 304 posts

Re: JSON Web Tokens should be avoided

#201

Post by mst »

tptacek wrote: post #77
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 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…

Seems like, practically, that suggests three options:

1. Take something like AS::ME that already has real use and implement it for as many platforms as possible

2. Define a really restricted subset of JWT (which may be necessary anyway for purposes of saying to management "yes, we're buzzword compliant")

3. Invent a non-AS::ME "bag-of-attributes secure bearer token" system and implement it everywhere.

I think part of the trouble with 3 is that people like me genuinely worry that if we tried to roll our own we'd manage to do worse than JWT in spite of JWT being terrible.

So maybe step zero is for somebody with crypto knowledge to explain one sane way to do the "bag-of-attributes secure bearer token" part ... or you to point the audience to a blog post that already exists that describes it, because, well, because I suspect quite a few of us trust you to say "this post actually describes a sensible plan" while we don't trust ourselves to be able to tell.

Re: JSON Web Tokens should be avoided

#202

Post by hodgesrm »

pilif wrote: post #139
throwaway2016a wrote: post #131

Earlier quoted context omitted.

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

cookies have one advantage over localStorage and custom headers though: They can be set by the server in a way that client-side JS code doesn't get to see or change them. This makes abusing XSS vulnerabilities to get to the token slightly harder.

"Slightly harder" is right. You can always write a non-JS client app, e.g., using Apache HttpClient. At that point the client can do anything it wants with headers.

Re: JSON Web Tokens should be avoided

#203

Post by deepanchor »

jdmichal wrote: post #172
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,…

This is exactly the solution I use. I use a secret server (Vault, using Consul as a backend) to securely distribute and manage the encryption keys.

Re: JSON Web Tokens should be avoided

#204

Post by Klathmon »

joepie91_ wrote: post #177
Klathmon wrote: post #49

Earlier quoted context omitted.

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.

The fact that an iOS UIWebView doesn't allow you to set 3rd party cookies in spite of what the user allows in Safari's settings is a security feature?

The fact that I can't get an app hosted at app.hostname.tld to send a cookie to api.hostname.tld when both the app requesting it allows credentials to be sent in the XHR request and the server is allowing app.hostname.tld to send credentials with the header Access-Control-Allow-Credentials on all platforms is a security feature?

The fact that I can't purge an HTTPOnly cookie in javascript without making a call to an endpoint is a security feature?

The fact that cookies default to JS readable and work across http and HTTPS and you need to make sure to set flags like "Secure" and "HTTPOnly" or you will be open to all kinds of attacks is a security feature?

The fact that cookies are sent on all requests on that domain and preventing browsers from doing that is what brought me down this path in the first place is a security feature?

Yes, there are security features that cookies give you that are extremely useful, however the downsides, bugs, differing implementations, arbitrary defaults, and the need to know the right set of flags and headers to send to make it secure aren't features. Not to mention that you STILL need to do things like CSRF-Protection to actually secure it.

Re: JSON Web Tokens should be avoided

#205

Post by unscaled »

tptacek wrote: post #195
unscaled wrote: post #191

Earlier quoted context omitted.

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.

Agreed, but is there a better standard?

I'm also fine with just stuffing MsgPack or Cap'n Proto data inside a libsodium secretbox or usually just crypto_auth to be honest, but corporates love standard. Perhaps libsodium algorithms should be turned into RFCs and then we could have a much simplified token metadata format (expiry, issued date and their ilk) that can be separated from a completely freeform payload. I'd gladly push that format over JOSE.

We can cry "just run an arbitrary format through HMAC-SHA256/libsodium" until the end of the days, but it's the same as asking developers to just send a list of key-value pairs during the XML overengineering heyday. Until JSON came with RFC hammer on their head, developers went with XML by default.

Re: JSON Web Tokens should be avoided

#206

Post by deathanatos »

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…

> is there any reason not to just slap a name on that "standard" and publish a bunch of libraries?

It was called JWT.

  jwt.decode(token, 'secret', algorithms=['HS256'])
That's the Python for JWT; encode is similar. You can try something like what you suggest, but the devil is in "object": want your token to expire after a finite amount of time? You'll need to encode that yourself. Token need to be valid only for certain cases? You'll need to encode that yourself. Essentially, you end up reinventing the part of JWT that is relevant to your use-case, and hopefully, arrive at a decent API.

At least in Python, python-jose's APIs will check not only the signature, but these additional claims (expiration of the token, that the token is applicable to the use we're verifying it for).

(I still think we should be moving towards a common API (and JWT is good enough) and building libraries around that standard. They're going to fall short in some ways at first, and I wish people would help improve them. The suggestion of using base64/libsodium feel dangerously close to "rolling your own", because its too low-level for the purpose at hand.)

Re: JSON Web Tokens should be avoided

#207

Post by daenney »

jjawssd wrote: post #181
chmike wrote: post #168

Earlier quoted context omitted.

When the authentication info needs to be used with servers in different location of the world, JWT is better. Getting the session info from a redis server or something equivalent isn't free. Deciphering a JWT token may be faster. So, the most appropriate method depends on the use case. If all the servers are in one location, a random byte sequence as session id key with cached info is the most simple, compact and eff…

Or you can use read only Redis replication and keep your architecture pretty much the same https://redis.io/topics/replication

What happens when that replication breaks? Can people still log in? Can you still validate their sessions? Or are you going to have an outage in a geographical region?

Re: JSON Web Tokens should be avoided

#208

Post by tptacek »

mst wrote: post #201
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…

Seems like, practically, that suggests three options: 1. Take something like AS::ME that already has real use and implement it for as many platforms as possible 2. Define a really restricted subset of JWT (which may be necessary anyway for purposes of saying to management "yes, we're buzzword compliant") 3. Invent a non-AS::ME "bag-of-attributes secure bearer token" system and implement it everywhere. I think part of…

Or just use Fernet:

https://github.com/fernet/spec/blob/master/Spec.md

Fernet was written originally for Python but there's a Ruby implementation, a Golang implementation, and a Clojure implementation. I believe that for at least 80% of applications considering JWT, Fernet provides exactly the right amount of functionality, and does so far more safely than JWT.

Re: JSON Web Tokens should be avoided

#209

Post by cainlevy »

mst wrote: post #201
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…

Seems like, practically, that suggests three options: 1. Take something like AS::ME that already has real use and implement it for as many platforms as possible 2. Define a really restricted subset of JWT (which may be necessary anyway for purposes of saying to management "yes, we're buzzword compliant") 3. Invent a non-AS::ME "bag-of-attributes secure bearer token" system and implement it everywhere. I think part of…

1. The reason AS::ME can be that nice is because it assumes a monolithic architecture and a single framework.

For example, AS::ME relies on shared secrets, which I think makes it unfit for distributed systems. Implementing JWK with asymmetric keys can really reduce provisioning and configuration costs. Keeping the signing secret on one private, hardened auth server (or cluster) also allows smart things like automated key rotation.

2. 100%. There's at least one right way to do JWT, but more ways to do JWT wrong.

3. JWT et al provide a fine starting point, I don't see a reason to start from scratch.

I'm not tied to the JWT spec, but I'm quite happy with what I've been able to accomplish using a careful implementation in my AuthN server: https://github.com/keratin/authn

Re: JSON Web Tokens should be avoided

#210

Post by tptacek »

unscaled wrote: post #205
tptacek wrote: post #195

Earlier quoted context omitted.

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

Agreed, but is there a better standard ? I'm also fine with just stuffing MsgPack or Cap'n Proto data inside a libsodium secretbox or usually just crypto_auth to be honest, but corporates love standard. Perhaps libsodium algorithms should be turned into RFCs and then we could have a much simplified token metadata format (expiry, issued date and their ilk) that can be separated from a completely freeform payload. I'd…

Sure: use Fernet.

https://github.com/fernet/spec/blob/master/Spec.md

It's an informal standard, like Noise, or WireGuard, or Curve25519, or Nacl. It's also so simple that JWT nerds will likely believe it's missing something. It is: the JWT/JOSE vulnerabilities.

It used to be that we got things working and then standardized them. Now we build cryptosystems de novo in standards committees and spend the next 10 years writing papers about the resulting flaws. Ok, it didn't used to be that way, and we've always been writing papers about flaws in crypto standards. I don't know what to say about this, except "stop, somehow".

Post reply on HN