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

221–230 of 304 posts

Re: JSON Web Tokens should be avoided

#221

Post by bgentry »

unscaled wrote: post #217
bgentry wrote: post #213

Earlier quoted context omitted.

Assuming that: - your JWT libraries don't do anything dumb like accepting the `none` algorithm - you're using HMAC SHA-256 - your access tokens have a short (~20 min) expiration time - your refresh tokens are easily revocable Can you elaborate on the specific security advantages that a token encoded with ActiveSupport::MessageEncryptor would have over such a JWT implementation? Why do you think there aren't more AS::…

You should also make sure to allow only tokens with the "HS256" alg headers before you verify them, in case somebody decides to add a new signature algorithm to your library, and it turns out it could easily be broken and lets you use the same key you used for HS256.

yes, that's another good point and probably something many folks mess up. I am explicitly specifying my algorithm for both encode/decode :)

Re: JSON Web Tokens should be avoided

#222

Post by tracker1 »

Personally, I've hand-written a few JWT implementations, and usually avoid even using a few of the "standards" often avoiding even reading the header. This is because usually I've used them for internal systems calling other systems.

If you avoid reading the header, and have standard policy on signatures, combined with very short lived tokens (max 1m) combined with https, there is minimal risk.

Yes, the standard is flawed, that doesn't mean the structure is inherently bad, or that using said design is bad by itself.

Re: JSON Web Tokens should be avoided

#223

Post by davewritescode »

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.

As shitty as XML-DSIG is, it's pervasively used across almost every single language and platform imaginable. The goal of standards like JWT and XML-DSIG is interoperability above security. What good is perfect security if you can only talk to yourself?

PS: libsodium is great but the fact that it requires C bindings to use from a JVM app makes it a non starter for a lot of use cases.

Re: JSON Web Tokens should be avoided

#224

Post by batoure »

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

You do understand that this is fundamentally the exact underlying mechanic of JWT?

Re: JSON Web Tokens should be avoided

#225

Post by tracker1 »

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…

For my service to service requests, I tend to require the token itself be set to an expiration of less than 1 minute from creation. I actually code 2min in the check, but document 1 for access clients. This allows for more than enough drift and with https mitigates the level of risk for replay attacks.

Beyond this a header/signature for the body/payload will reduce the risk of the rest.

As to being able to select the signature algorithm, or set the uri for the public key... ignore this, or whitelist domains or methods. Yes, there's some wholes regarding a "by the books" implementation... that doesn't mean you need to support the entire spec.

I implemented about 1/2 the SCORM spec in an API once, and it was 8 years before a specific course needed a part that was missing. Yes, it isn't 100% compliant, but if it does the job, and is more secure as a result, then I'm in favor of it.

Re: JSON Web Tokens should be avoided

#226

Post by tracker1 »

unscaled wrote: post #217
bgentry wrote: post #213

Earlier quoted context omitted.

Assuming that: - your JWT libraries don't do anything dumb like accepting the `none` algorithm - you're using HMAC SHA-256 - your access tokens have a short (~20 min) expiration time - your refresh tokens are easily revocable Can you elaborate on the specific security advantages that a token encoded with ActiveSupport::MessageEncryptor would have over such a JWT implementation? Why do you think there aren't more AS::…

You should also make sure to allow only tokens with the "HS256" alg headers before you verify them, in case somebody decides to add a new signature algorithm to your library, and it turns out it could easily be broken and lets you use the same key you used for HS256.

If it's your software generating the tokens, then that means they'd need the shared key, or private key in order to sign the token... which is already a problem. Now if you're accepting tokens from a third party, that's another issue, and should be much more constrained.

I go farther still and require a VERY short expiration on service to service requests (documented as 1m, coded as 2m) which combined with https limits the chance of replay attacks.

Re: JSON Web Tokens should be avoided

#227

Post by batoure »

jacopofar2 wrote: post #7

The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header ( https://github.com/auth0/node-jsonwebtoken/blob/master/verif... ) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your a…

session invalidation is actually very easy to implement. Its important to think of it as a process instead of a builtin to the standard.

In most of our implementations we achieve this by differentiating between the session token and a request token. Requests that actually power the app use tokens that are very short lived. Request tokens are generated by the core auth server using the session token. A session can be invalidated at the core auth server which will then refuse to give request tokens to the bearer.

Re: JSON Web Tokens should be avoided

#228

Post by jjawssd »

daenney wrote: post #207
jjawssd wrote: post #181

Earlier quoted context omitted.

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?

Fall back to connecting to the main instance directly

Re: JSON Web Tokens should be avoided

#229

Post by tracker1 »

cainlevy wrote: post #209
mst wrote: post #201

Earlier quoted context omitted.

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…

Agreed... my first two experiences with JWT were creating my own implementation... in my case, the allowed public keys had to come via https from a specific server in the domain, even without PKI using shared key... I had hard coded the algorithm used for the signature. This could just as easily be filters on a library though, it's just my first experience didn't have a valid library, so I had to composite one (did use existing crypto library though).

JWT is a perfectly valid structure, even if the spec is more flexible than it should be. By that matter, https also has historically supported algorithms and protocols later broken. Nobody is suggesting we stop use HTTPS, only that we limit acceptable protocol and algorithms supported.

Re: JSON Web Tokens should be avoided

#230

Post by jdmichal »

batoure wrote: post #224
jdmichal wrote: post #172

Earlier quoted context omitted.

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

You do understand that this is fundamentally the exact underlying mechanic of JWT?

You call it the underlying mechanic. I call it the only necessary mechanic. If those additional mechanics are where the security issues come from, then just get rid of them.
Post reply on HN