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

281–290 of 304 posts

Re: JSON Web Tokens should be avoided

#281

Post by Illniyar »

deathanatos wrote: post #272
Illniyar wrote: post #252

Earlier quoted context omitted.

CSRF is the easiest vulnerability to avoid, a csrf token solves all csrf attacks. XSS is a lot harder to protect against, one of the better ways to mitigate it's effects is to use http only cookies

Well, I keep running into CSRF vulns. in the wild, so… XSS is avoidable by systematically having a framework that escapes any inputs that are run through it. (jinja2, on the server, can do this, though it defaults to not , which I wish wasn't true.) I'm not saying that XSS is much better that CSRF, really; I've seen these, too. the point (and that of the linked article) is more that either you're not subject to XSS,…

The idea that Session Hijacking attacks are irrelevant when a user can use XSS to perform any action on the client is interesting.

Definitely if your service is a valuable target that hackers will spend the time to reverse engineer your client code to create custom tailored XSS attacks then protecting against Session Hijacking does seem to be pointless.

But session hijacking is considered to be a very common attack (though I can't find any real numbers anywhere, maybe it's not?), most services with low attack value will probably be better served by httpOnly cookies and csrf tokens that make worthwhile XSS attacks more time consuming then preventing XSS altogether, which is an enormous, continuous effort.

Also your implying that CSRF is hard to defend against (otherwise why do you keep running into it) but in the same breath saying that XSS is simple to defend against.

If people can't defend against CSRF (which is usually just a simple flag for most frameworks), they aren't prepared to defend against XSS which means getting into a security mindset in all things. A serverside template is not enough - XSS can manifest in headers, in clientside code, in third party code, in redirections and it is easy for a developer to mistakingly add a new attack surface.

Re: JSON Web Tokens should be avoided

#282

Post by yuhong »

tptacek wrote: post #79
regecks wrote: post #50

Complaining about OAEP when RSA-OAEP is perfectly safe seems needlessly straw-grasping, the other complaints (should) stand perfectly well on their own. I've used JWT in three languages and the API has always sucked, really badly. I always end up with a verbose heap of gunk - and in some cases, like jwt-go, there is not even a complete example of use in the README + docs. mfw. It should not take multiple steps to sig…

I agree. The OAEP thing was weird.

In fact, JWE and JWS are not as flawed as JWT is, right? ACME uses JWS.

Re: JSON Web Tokens should be avoided

#283

Post by yuhong »

tptacek wrote: post #235
tracker1 wrote: post #229

Earlier quoted context omitted.

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

No, almost everybody in the field laments SSL and TLS. It's probably too late at this point --- and has been for well over a decade --- to get to something better than TLS, and so TLS 1.3 is what we're stuck with. But that is demonstrably not the case with JWT. We don't have to convince all the browser vendor to upgrade out of JWT in lockstep. Avoiding another 20 years of hair-on-fire crypto vulnerabilities seems rea…

And I think JWT is more flawed than SSL/TLS.

Re: JSON Web Tokens should be avoided

#284

Post by contrast »

tptacek wrote: post #180
danjoc wrote: post #161

Earlier quoted context omitted.

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

"Contribute to standards processes" and "don't roll your own" aren't moral arguments. They're complimentary pieces of practical advice on how to make trustworthy systems.

Meanwhile your comments bury whatever substantive content they might hold under layers of emotional, accusatory garbage. Maybe get those feelings locked down a bit before posting?

Re: JSON Web Tokens should be avoided

#285

Post by Flenser »

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

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.

Since it's not linked from any https://github.com/fernet/ project as far as I could tell, and I had to google for it.

Clojure implementation:

https://github.com/derwolfe/fernet-clj

I also found a JavaScript implementation:

https://github.com/csquared/fernet.js

Re: JSON Web Tokens should be avoided

#286

Post by nb777 »

unscaled wrote: post #170
Alex3917 wrote: post #149

Earlier quoted context omitted.

> they may keep you up late on a Friday scrambling to deploy a token blacklist Because every token has an iat datetime, you don't need a token blacklist to invalidate tokens. You just need some sort of tokens_invalid_if_issued_before_datetime setting that gets checked whenever you validate the signature of a token. The alternative is to store a UUID for each user, and just rotate those whenever they log out, change o…

Agreed. Revoking all user sessions instead of a specific token is the common case. The only usage I see for revoking a specific token is when the user is deactivating a specific client.

Also when a user changes his password, no ?

Re: JSON Web Tokens should be avoided

#287

Post by robertlagrant »

stephenr wrote: post #187
StreamBright wrote: post #13

>> A lot of developers try to use JWT to avoid server-side storage for sessions. This is based on what? Sounds like he just made it up. His other claims does not look sound to much more either. I would like to see a more in-depth analysis on the subject, this all looks very hand-wavy to me.

> This is based on what? Based on the entire reason JWT is even a thing? Developers love to believe every app they build is going to run at the scale of Facebook to the power of Google times Twitter, and thus needs to run on 10,000 Docker instances spread across 15 data centres around the globe (and soon, one on the moon!). Relying on server-side sessions is "terrible" because you have to talk to the backend, and you…

I wouldn't say it's impossible to invalidate them individually. It's certainly more effort, and it's probably better to have short-lived session tokens and refreshing, but I think it can be done.

E.g. what about a message bus that publishes an invalid token message that is subscribed to by the API-providing systems, so they can maintain a prematurely-expired tokens list?

On the keeping info in Javascript vs keeping it in a cookie issue, I don't understand that so well. If you made the token a private member of an object that was responsible for the calls, would that help? Then no code could access it?

Re: JSON Web Tokens should be avoided

#288

Post by davewritescode »

tptacek wrote: post #234
davewritescode wrote: post #223

Earlier quoted context omitted.

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.

I don't know how to respond to this in any other way than to say that it's unethical to build systems you know have security weaknesses.

1 - You have not demonstrated in anyway that it's impossible to use JWT tokens in a secure manner. Just that it's easy to shoot yourself in the foot.

2 - It's not unethical to make tradeoffs, period. We all build systems that have potential attack vectors and we make tradeoffs based on threat models. That's the difference between Academics and Engineers.

Example: Hacker News allows shitty passwords, that's a security weakness. However, the data that's protected by that shitty password is pretty meaningless. Is that not a good security tradeoff? Is Hacker News unethical?

Re: JSON Web Tokens should be avoided

#289

Post by stephenr »

robertlagrant wrote: post #287
stephenr wrote: post #187

Earlier quoted context omitted.

> This is based on what? Based on the entire reason JWT is even a thing? Developers love to believe every app they build is going to run at the scale of Facebook to the power of Google times Twitter, and thus needs to run on 10,000 Docker instances spread across 15 data centres around the globe (and soon, one on the moon!). Relying on server-side sessions is "terrible" because you have to talk to the backend, and you…

I wouldn't say it's impossible to invalidate them individually. It's certainly more effort, and it's probably better to have short-lived session tokens and refreshing, but I think it can be done. E.g. what about a message bus that publishes an invalid token message that is subscribed to by the API-providing systems, so they can maintain a prematurely-expired tokens list? On the keeping info in Javascript vs keeping i…

> I wouldn't say it's impossible to invalidate them individually

It's impossible to invalidate individual "stateless" JWT's.

If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole purpose of using JWTs (being stateless).

> On the keeping info in Javascript vs keeping it in a cookie issue, I don't understand that so well.

Cookies can be set HTTP only. They're sent to the browser, and it will send them back when making requests as per usual, but they're not exposed to JavaScript, at all. There is 0 way for malicious (or non malicious) client side code to see these cookies, thus 0 way for malicious javascript to steal one used as a session cookie.

> If you made the token a private member of an object

If the data can be read from the network by your JavaScript, it can be read from the network by their JavaScript.

Re: JSON Web Tokens should be avoided

#290

Post by cygned »

justinclift wrote: post #109
falcolas wrote: post #95

Earlier quoted context omitted.

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.

Hmmm, using a database (eg PG) for the authoritative information, with memcached in front sounds like it would be practical for most uses.

Postgres is not a good solution for this kind of data. I'd use Redis, but maybe there are even better products.
Post reply on HN