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

How to Use JSON Web Tokens

github.com

Post reply on HN
Print view View original

101–110 of 135 posts

Re: How to Use JSON Web Tokens

#101

Post by jondubois »

groestl wrote: post #90
jondubois wrote: post #42

I think storing JWTs might make sense for some advanced scenarios where you have multiple services with varying security requirements but when you store JWTs, you lose a lot of the benefits of having a stateless token which doesn't require a database lookup. A possible alternative is to just make the JWT expiry very short; like one hour; then you don't really need to explicitly invalidate the token. With a real time…

An hour could be much much too long, depending on what service you are protecting. It's long enough that even assuming that token theft is a non-stealthy operation, and the user reacts immediately, the attacker has a lot of time to execute his attack. For things like Facebook, this could include slowly scaping all user data and spreading the infection vector to other users. As for websockets: session integrity is han…

Storing JWTs in a store or DB is difficult because you need to manage them and that means accounting for all possible edge cases. You can't always detect when a WebSocket/TCP connection has closed from the back end. For example, if your WebSocket server crashes suddenly, all active JWTs that you keep in your external data store will be orphaned and they won't get cleaned up until you run a separate cron job (which adds a lot of complexity).

Storing JWTs in a hashmap in memory is also not ideal if you have multiple processes/servers because it doesn't account for WebSocket lost connection and reconnection edge cases; the client could reconnect to a different server/process than before.

Re: How to Use JSON Web Tokens

#102

Post by tptacek »

ljm wrote: post #97
kevinburke wrote: post #84

Earlier quoted context omitted.

Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509. It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.

I don't think X509 or public key crypto is as scary as it looks, once you understand what you're actually dealing with and how the openssl related libraries work. There is definitely a UX issue though, and—without intending to be disrespectful—junior devs coming into programming through Javascript, or building basic microservices, are going to see a lot written about JWT and how easy it can be to work with, and sudde…

I'd like to hear more about why X.509 and public key aren't scary, when the prevailing attitude in the crypto engineering community is that they're terrifying sources of surprising game-over vulnerabilities. How many people do you think there are in the world that can reliably and safely evaluate an arbitrary X.509 document in a de novo implementation?

Re: How to Use JSON Web Tokens

#103

Post by tptacek »

Freak_NL wrote: post #43
mattferderer wrote: post #39

Earlier quoted context omitted.

> 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it Not a JWT expert but isn't this the point of a JWT or am I missing something. Sharing data between servers & clients while being able to make sure the data wasn't changed. > 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conf…

Libraries did that. Most now guard against this by forcing the developer to explicitly enable the 'None' algorithm. Normally you don't need it, and certainly never in production. But yeah, if your server accepts JWT's, reject anything that doesn't use an algorithm from your whitelist, which usually contains just one entry.

Most libraries do guard against this. But the point of a "standard" like JOSE/JWT is that you don't have to depend on a library; you should be able to consult the spec and build your own library. And, of course, alg:None is yet another pitfall that JOSE pointlessly opts you in to; it's yet another thing you need to know to safely implement JWT (it's far from the trickiest thing you need to know!)

Re: How to Use JSON Web Tokens

#104

Post by tptacek »

andrewstuart2 wrote: post #76
TekMol wrote: post #75

At first JWTs look cool because you can log in users without managing session data on the server. Then you think about how a user can actively log out. Then you add session management to your server but call it 'token invalidation'.

This is a problem you have with any federated token-based identity solution. Distributed logout is a hard problem which can basically be reduced to cache invalidation (insert N/N-1 hard things in CS joke here).

This is a little like saying "this is a problem you have with ANY identity solution that looks like JWT". Yes, that's true. The reason people complain about JWT is that (a) it's the most popular solution of this shape, and (b) people use it without understanding why they're using it or whether the tradeoffs work for their application. They usually do not.

Witness everyone saying that the important feature of JWT is that it's standard and interoperable, as if that was a mandatory feature of most token-based authentication schemes; in fact, the "portability" of JWT is a security liability for --- I'll hazard --- the overwhelming majority of applications.

Re: How to Use JSON Web Tokens

#105

Post by fenwick67 »

beardedwizard wrote: post #14
deathanatos wrote: post #11

Earlier quoted context omitted.

> JWTs can be read by every script you add to your site, making XSS attacks easier. A cookie with the HttpOnly flag prevents this. You're confusing JWTs (a standardized token / means of representing claims) and JavaScript localStorage (a storage which can be read by scripts, partitioned by origin). The two are completely orthogonal; you could store a JWT in a cookie, if you wanted to. > JWTs [… make] XSS attacks easi…

CSRF is mitigated by using the samesite cookie flag. XSS is mitigated by httponly, except where XSS makes legitimate requests to domains specified by the cookie. This article describes some of the most vulnerable ways to use a JWT in 2019, but please let's stop talking about none algorithms.

samesite doesn't appear to work in Safari, IE or Edge sadly.

EDIT: apparently it's a bit more complicated than that: IE11 on windows 7 doesn't support it, and Safari https://caniuse.com/#search=samesite

Re: How to Use JSON Web Tokens

#106

Post by tptacek »

andrewstuart2 wrote: post #79
incadenza wrote: post #50

Earlier quoted context omitted.

My issue here is that expiring JWTs involve adding state! The whole point of JWTs is stateless authentication, so I’ve never understood the advantage over sessions unless revoking tokens is never an option.

Invalidation of any sort, including token revocation, is fundamentally a stateful operation. Either you are deleting session state or statefully blacklisting something that's a packet of self-contained state (e.g. JWT by id). Heck, even expiration just reduces the revocation into the universally shared state that is time. My point is, you always have state. If you care about that state being anything but _the current…

If you always have state, what's the point of making tradeoffs to get closer to "statelessness"?

I see clearly why some small subset of applications benefits from carefully minimizing shared state among components. It is not at all clear to me why pseudo-statelessness is a good default.

Re: How to Use JSON Web Tokens

#107

Post by leejo »

danesparza wrote: post #91
schnable wrote: post #49

Earlier quoted context omitted.

JWT is just a standard for bearer tokens (including those used by OAuth 2).

I originally thought so myself. But RFC 7519 ( https://tools.ietf.org/html/rfc7519 ) is different from RFC 6750 ( https://tools.ietf.org/html/rfc6750 ) -- and the two don't mention each other's implementation.

RFC 6750 describes the format of Bearer tokens: https://tools.ietf.org/html/rfc6750#section-2.1 # it happens than JWTs fit the format, so they can be used.

The spec is vague enough here that you can stuff almost any string you want into the header, as long as it has sufficient entropy that it is near impossible to brute force. Of course, JWTs introduce their own concerns, as discussed in other comments.

Re: How to Use JSON Web Tokens

#108

Post by andrewstuart2 »

tptacek wrote: post #100
andrewstuart2 wrote: post #81

Earlier quoted context omitted.

There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails. Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your…

In the context of security analysis, this is a vacuous statement. There's almost always something you can do to screw a security construction up. An important goal of security engineering --- and the overriding goal of modern cryptography engineering, in particular --- is to minimize the set of things that can go wrong. This is why we generally feel safer deploying Rust and Go code than C code, why we use Curve25519…

To be honest, and with all due respect, avoiding JWT outright feels a lot like a cargo cult to me. I have yet to see a solid argument against JWT itself, aside from the criticisms you just gave of "it doesn't minimize the set of things that can go wrong." In reality, that statement is like saying "x509 doesn't minimize the set of things that can go wrong."

The criticism is leveled at JWT as if the JWT spec attempts to be anything but "a compact, URL-safe means of representing claims to be transferred between two parties," to quote the spec. I think JWT is better understood as what it intends to be, a simple standard for easily-understood claim sets, that more finely detailed, granular, and secure standards can be built atop.

Admittedly, I'm reading about macaroons for the first time, but from what I can tell they're a higher level concern than something like a JWT. I'm not sure I would actually try it, because it wouldn't be very efficient, but I'd wager you could implement macaroons securely, using JWT as the container for the claims (including claimed constraints) and HMAC signatures.

Maybe I'm totally off base, and if so I'd love to take the time to understand how, but I don't see how JWT as the tiny spec it is, or JWS/JWE, again rather small specs, have done anything to maximize what can go wrong, as much as they are deliberately reducing their surface area to be composable, and to allow other standards to compose them into more secure, minimally faulty specs.

Re: How to Use JSON Web Tokens

#109

Post by geezerjay »

incadenza wrote: post #94
geezerjay wrote: post #88

Earlier quoted context omitted.

> Why would you arbitrarily reject a token refresh? You've misread what I've said. The server can trigger token refreshes by rejecting the request. According to the JWT workflow, that triggers the client to request a new token and retry the request. > The question here is which token to reject. That isn't much of a question, because servers are free to reject any token arbitrarily. They can, however, ignore specific…

I'm failing to see how this is complicated. Imagine the following: 1) A token gets compromised. 2) You know which token. You need to revoke access. 3) You introduce state by storing said token on disk / in memory somewhere. Key takeaways: 1) The authentication system (not the token) is now stateful. 2) You now have to check this data store to properly allow authentication. 3) A core benefit of JWT (stateless auth) is…

> 1) A token gets compromised.

Tokens are single-use and short-lived. Once a token is used it's revoked.

> 2) You know which token. You need to revoke access. > 3) You introduce state by storing said token on disk / in memory somewhere.

You don't. You simply reject the token and let the client refresh its token. That's it. There is no state. Compliant clients already expect tokens to be rejected for no apparent reason. They are access tokens.

Why exactly are you assuming that an access token is not single-use or even short-lived, particularly in bearer token protocols specifically designed so that tokens are ephemeral and single-use?

> 1) The authentication system (not the token) is now stateful.

Even if you shoehorn your definition of statefulness, that's entirely irrelevant. The whole point of an authentication system is, following your line of reasoning, to implement a stateful system. Thus, not only is that line of reasoning absurd, it also completely misses the point of implementing an authentication system, not to mention it ignores a whole class of attacks. And for what, exactly?

Re: How to Use JSON Web Tokens

#110

Post by tptacek »

andrewstuart2 wrote: post #108
tptacek wrote: post #100

Earlier quoted context omitted.

In the context of security analysis, this is a vacuous statement. There's almost always something you can do to screw a security construction up. An important goal of security engineering --- and the overriding goal of modern cryptography engineering, in particular --- is to minimize the set of things that can go wrong. This is why we generally feel safer deploying Rust and Go code than C code, why we use Curve25519…

To be honest, and with all due respect, avoiding JWT outright feels a lot like a cargo cult to me. I have yet to see a solid argument against JWT itself, aside from the criticisms you just gave of "it doesn't minimize the set of things that can go wrong." In reality, that statement is like saying "x509 doesn't minimize the set of things that can go wrong." The criticism is leveled at JWT as if the JWT spec attempts t…

I'm not sure how you can "cargo cult" not casually adopting some random piece of technology. The Pacific cargo cults transformed incidental interactions with modernity into religious venerations; aboriginal islanders got free supplies from visiting GIs, believed the experience to have been supernatural, and built wooden airplane replicas as idols in hopes of summoning those benefits anew. The comparison to JWT is pretty clear: people add these coconut phones to their applications in hopes of gaining some ineffable "cryptographic security". Meanwhile: the cryptography engineers look on in baffled wonderment.

I've written many, many times on HN about problems with JWT and I'm by no means the foremost critic of the standards. Here's a starting point:

https://news.ycombinator.com/item?id=14292223

I don't know anyone competent who believes the JWT/JOSE specs to be "tiny"; for instance, they incorporate X.509.

Here's a piece we wrote last year that goes into the tradeoffs between different inter-service auth mechanisms (including Macaroons), and discusses the various attributes you might, in the abstract, get from them:

https://latacora.micro.blog/2018/06/12/a-childs-garden.html

The problems JWT attempts to solve are harder to solve outside the inter-service auth context.

You are, respectfully, totally off base.

Post reply on HN