JSON Web Tokens should be avoided
paragonie.com
paragonie.com
(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 alternatives.
I could care less about JWT per se. I'm happy to implement a similar pattern with something else (e.g. store a secure cookie post-auth, skip all the refresh business and just let it expire when it expires, and employ an ugly revocation strategy only if absolutely necessary). I don't need JWT for this.
If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies. Although I suppose you could argue that a cookie is just another header value.
Either way, if you're serving up a REST API to a JavaScript UI... what's NOT a good option is server-side session state (e.g. Java servlet sessions). That requires you to either: configure your load balancer for sticky-sessions, or employ a solution to share session state across all your server-side instances (which never works very reliably). Moreover, relying on a session isn't a very RESTful auth strategy in the first place.
So if I'm writing a SPA in 2017, then I'm definitely taking a client-side approach and running afoul of the #2 critics. And since JWT is so widely implemented (e.g. if I use a "Login with Google" option then I'm using JWT), I'm probably running afoul of the #1 critics too.
These criticism are fine, I guess. There's no faster route to blog clicks, book sales, speaker invites, and consulting dollars than: (1) telling everyone to jump on this year's hype train, or (2) telling everyone that last year's hype train sucks. What the world really needs is a bit more actual prescriptive recommendations of what to do instead.
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, you as a developer won't see that complexity: JWT looks like a simple token with a magic cryptographically-protected bag-of-attributes interface. The problems are all behind the scenes.
For most applications, the technical problems JWT solves are not especially complicated. Parseable bearer tokens are something Rails has been able to generate for close to a decade using ActiveSupport::MessageEncryptor. AS::ME is substantially safer than JWT, but people are swapping it out of applications in favor of JWT.
Someone needs to write the blog post about how to provide bag-of-attributes secure bearer tokens in all the major programming environments. Someone else needs to get to work standardizing one of those formats as an alternative to JWT so that there's a simple answer to "if not JWT then what?" that rebuts the (I think sort of silly) presumption that whatever an app uses needs to be RFC standardized.
But there's a reason crypto people hate the JWT/JOSE/JWE standards. You should avoid them. They're in the news again because someone noticed that one of the public key constructions (ECDHE-ES) is terribly insecure. I think it's literally the case that no cryptographer bothered to point this out before because they all assumed people knew JWT was a tire fire.
What is the significance of that part?
Of course, it'd be better still to use a format _meant_ to provide human-readable canonical representations of data, e.g. Ron Rivest's canonical S-expressions (http://people.csail.mit.edu/rivest/Sexp.txt), but of course this is information technology and we have to reinvent the wheel — usually as an irregular polygon — every 3-4 years rather than using techniques which are tried and true.
Presumably this means that you have to have have a "flat" JSON structure rather than lots of nested objects and arrays?
Could you give more info about this? If ECDHE-ES is avoided why else is JWT insecure?
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 or reset their password, or there is some sort of security event. These are then stored in the payload and used as a secret. The one advantage over just using dates is that with the former, there can be weird bugs if you have multiple servers with clocks that are out of sync.
But you shouldn't ever need to blacklist specific tokens, at least not unless you have some highly specialized use case.
Is that not effectively a server-side session?
With most web frameworks (e.g. Django), the user model is retrieved on every request anyway. So it would be perhaps more accurate to say that it's a server-side session that's effectively not a server-side session, since no additional lookups are needed, only the user model lookup that's already done anyway.
No, because you would also store either a separate datetime or uuid on each user model. And if just one user has their credentials compromised, then you would bump the date or generate a new UUID for just that user.
The global datetime would only be bumped if some site wide vulnerability were found.
That's what I do in my system.
Proponents say critics dont offer alternatives at the same time they always literally 'reverse' engineered sessions if you dig deep enough.
I give up. JWT is just a hip thing to do right now. :(
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 solicited?
>I think it's literally the case that no cryptographer bothered to point this out before because they all assumed people knew JWT was a tire fire.
Oh. Cunningham's Law. You know, if you're not part of the solution, you're part of the precipitate.
That's some considerable JWT fallout, since companies making a business out of security are endorsing it. Auth0 for example, https://auth0.com/docs/jwt
Until I read this article, I was under the impression JWT was the best new thing.
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.
If you have access to an experienced devops team who can securely maintain an nginx server with some proxy logic then maybe that's a possibility, but otherwise what other viable options are there? Wishing that JWT were more secure won't make it so, but neither will wishing that CORS were more flexible. And if it's a choice between subclassing the JWT handlers to provide a couple extra security checks vs trying to securely configure and maintain a whole extra proxy setup, then the former seems like the lesser of the evils.
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?
[1]: https://docs.aws.amazon.com/cognito/latest/developerguide/am...
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.
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.
Am I right that this would work fine both in that or in e.g. a query parameter?
(sorry if I'm asking really stupid questions, but I'd rather look stupid than accidentally a security hole)
Clojure implementation:
https://github.com/derwolfe/fernet-clj
I also found a JavaScript implementation:
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
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.
- 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::ME implementations out there if it's a superior solution? I only know of a Go implementation and haven't seen others: https://godoc.org/github.com/mattetti/goRailsYourself/crypto
Edit
I saw you mention Fernet in another comment. As a Heroku alum I'm quite familiar with Fernet (we used it for lots of things), but to my knowledge those projects are on life support at best.
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.
HMAC is great for monolithic architecture, but I've quite enjoyed using asymmetric RS256. I don't think that's something AS::ME offers.
My (limited) understanding is the security issues arise around the implementation & handling some of the default claims (NBF, IAT, etc.) and producing/verifying the signature.
But I don't quite understand how moving to a different format solves these issues?
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.
The OP article makes it sound like it's impossible to use JWT correctly, but I was under the impression that if I 1) am the issuer, and 2) I hardcode a single algorithm on my API endpoints, that neither of the issues in the OP apply. (The EC issue would apply if that algorithm was chosen).
Is there a safe subset of JWT? And isn't there value to small players in using the safe subset of JWT which is battle-hardened by guys with big security teams like Google?
Can you explain what you mean, as oppose to other kinds of session tokens?
Roy Fielding makes it abundantly clear[0] in the seminal delineation of REST that
We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
[0]https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
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.
Not many. I've made a good career out of consulting people who are doing REST wrong :)
Usually they are either storing state or forgetting about HTAEOAS (Hypermedia). Often they are also negotiated format and version incorrectly and in a way that doesn't scale.
A server with 1GB can hold a lot of JWT's in memory. Probably more than most of the people building services here have to actually deal with.
No? Maybe? It depends on your load balancer. Assigning a client to a specific server is "sticky sessions". Many of us don't want to tie a client to a specific server and prefer a completely stateless 12-factor-style mechanism where any server can serve the client and stateless tokens provide a mechanism to achieve this.
without revocation. What's wrong with tieing a client to a server, or co-located server? Either they are close enough to share tokens / sync fast, or not?
Nothing, if you can get away with it. What do you do if your server dies or is overloaded? The 12-factor patterns came to be for services running on ephemeral hosts in cloud environments. Stateless servers mean you can seamlessly serve requests from another server without problem. Sure, you can store the sessions in a shared resource (redis perhaps?) but this complicated failover and redundancy and may add latency.
Maybe this isn't an issue, maybe it is. If you don't need or want that, then just use normal sessions, for sure.
Revocation can be handled (although admittedly not as well as with sessions or stored tokens) through short TTL's and refresh tokens (which are stored, but only need to be looked up when the stateless token expires). Its not perfect, but its often a good enough tradeoff.
Your tokens should generally have a rather short lifetime - then you can keep the entire relevant window of revocations in memory.
The implementation is not trivial though, that's for sure.
By your measure, 1GB can store a lot of tokens in memory: 32B tokens + that again as metadata (e.g. user ID + TTL in Redis) = 15,625,000 tokens.
And you're overestimating the necessary size of a revocation store. Only a tiny fraction of your users ever log out or otherwise invalidate session via means other than TTL. You're looking at storing just a couple thousand 4-8 byte revoked session ids and ttls instead of gigabytes of session data.
If you have a security breach and need to invalidate all tokens, just reject all tokens with an issue date before it's fixed. And they all fall off anyway after a week (or however long the ttl is).
For client-server a 5 minute refresh is fine, as long as you do a lookup for refresh, so you can expire refresh tokens, requiring a full re-auth.
OAuth2 + JWT is fine... just whitelist the algorithms you allow and use HTTPS for all communications, even internal.
Aren't cookies just strings passed as HTTP headers?
But if I write some code using DRAKMA, urllib or net/http, and can see those cookies just fine.
(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-...
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.
* Use SameSite cookies (unfortunately, not yet supported by all browsers)
* Don't accept application/x-www-form-urlencoded, multipart/form-data, or text/plain at your endpoints, or
* Use CSRF tokens if you need to accept server-side rendered HTML forms
XSS is a lot harder to protect against, one of the better ways to mitigate it's effects is to use http only cookies
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, in which case localStorage is strictly better than cookies (it is default-secure), or you're subject to XSS, in which case neither saves you.
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.
> Although I suppose you could argue that a cookie is just another header value.
So... yes.
But yes, it is.
Server-side session tokens stored in the database worked fine ten years ago, and they work fine today. No need to muck with the load balancer.
Stateless tokens are great too, and use two-factor auth when you need that extra layer of security. No need for newfangled standards; HTTP Basic remains a simple and effective way to convey that token.
This is as opposed to < 0.1ms for verifying a JWT. JWT is a structure for stateless tokens... once you have a token, what does 2FA add? nothing. Also, some algorithms are insecure, so don't use them, or blacklist them... Or, better whitelist the algorithm you do use.
Very short lived JWT mitigates this as the window for replay is reduced, over HTTPS by the time you can crack it, that window is effectively gone. The server can verify a signature on a JWT in a fraction of a second... far faster than a DB call... Not including replication issues.
I don't hate secure cookies or anything, but some people act like plain-old regular cookies haven't been thoroughly solved by this point.
Related: Something people get wrong a lot with secure cookies is worrying about obscuring the cookie more than securing it. Encryption does not give you authentication; you need MAC for that. An encrypted message can still be blindly modified. Imagine being able to change a UID stored in a "secure" cookie even if you couldn't 100% control which. Eventually, if you try enough permutations, you're going to escalate your privileges!
Need an emergency revoke of every token? Easy: Replace your signature key. Any older token will fail signature verification. In which case, your system should require authentication and then generate a new token with an updated signature.
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 efficient.
You have a single page webapp that uses two APIs for part of the application. For security reasons the APIs are zoned in such a way that neither of them can communicate with each other. The machine of the user sits in a zone where it can send HTTP requests to the zones of either API.
Now design a way to manage sessions across both APIs...
There are certainly a number of ways to accomplish this, but JWT was the cleanest and most performant.
Dear Americans, the queen would like you to stop saying "could care less" - by David Mitchell of Peep Show
Between that and the incessant use of the incorrect phrase "for free" instead of the correct phrase "for nothing" it's amazing that I can stand to read anything on the internet.
xD
xD
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.
Isn't this how HTTPS works, HTTPS today doesn't use the same SSL and algorithms allowed in 1996, it's evolved and changed in practice. The author isn't suggesting everyone just not use HTTPS because some possible algorithm has been determined to be weak is he?
I think this is a very interesting, because it's basically validating the article's argument. People are going to feel safe implementing JWT because it's an RFC, without knowing where these "generally bad idea" landmines are. That's the dangerous part.
And yes, the same issues exist in SSL / TLS. And guess what? There's loads of articles just like this one stating how dangerous older modes of these protocols are. Articles like this and the discussions they spawn are exactly the kind of thing necessary to move the world forward into safer implementations.
Nobody has to implement the FULL spec, you only need to allow what your environment needs.
I just want you to know that such tactics are not very appreciated from this side of the conversation.
What does JWT provide that using bog-standard crypto primitives in the way I described doesn't? Other than a name and a standard?
Here is a point of order for developers who work on something realize it isn't idiot proof (them proof) out of the box and then want to write a sensational post:
Implementation and design are a core part of anything you do and considering the risks and accounting for them are part of doing business.
Having worked with large organizations that do active and passive scanning of the web I am constantly shocked how often we are contacting someone about basic SQL injection in their application... in 2017.
JWT is an incredibly powerful standard if implemented effectively but its not for the LAZY, it requires thoughtfulness where ever it is active.
JWT solves a serious and real problem that organizations face at scale which is why you see it implemented in systems like google sign in. Realistically its not going anywhere.
People love criticizing the movement towards stateless tokens on the web I find it pretty funny... crawl down the stack from their webheads and you usually come face to face with Kerberos managing auth within their networks...
The purpose of this article it criticize the standard, not particular libraries.
But when is the last time we see any technology successfully prevented people from being silly?
[1]: https://github.com/teotwaki/grace-calendar/blob/develop/app/...
Edit: DYAC.
It's a good thing that cookies have never been used in a bad manner. /sarcasm
You can never stop someone sufficiently motivated to shoot himself in the foot from doing it. But you can make it harder for those who would do it be accident by providing more safety features - in case of security this is usually seen as a good idea (safe defaults etc.)
Do not give people options, do not allow algorithmic flexibility, do not have fallbacks, do not have backward compatibility, do not allow "testing" or "insecure" options, do not have complex state machine behavior.
All of these things are exactly what JWT or other "design by commission" standards like SSL suffer from and they have predictably lead to ongoing, at times unfixable security problems.
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 would amount to the same thing.
Originally I implemented it because:
* My systems are SPA's. Totally JS dependent from the word go.
* I felt like there would be some advantages to being able to establish certain claims without verification. Say for display purposes prior to server comms (show a list of multiple available sessions for example)...In practise this hasn't really been true. Generally I find in the end I am always checking and verifying anyway - without any huge overhead.
* I've always had a sort of fuzz of uncertainty about Cookies. They always felt a bit out of my hands. Thinking it about rigorously of course, people can switch off JS. They can switch off persistence.
* All my user's local data can be persisted in one place, rather than having to store a reference in the Cookie and then lookup in localStorage. In reality though the code for this is pretty trivial...
So overall while I don't know how right he is, I feel like maybe he has a point. Why not just use cookies?
Maybe it's just because as a JS dev, I want everything to stay within a JS universe...and for some reason Cookies have always felt outside of that to me.
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 without doing a web request (which is annoying as hell if you are trying to keep a "logged in" state in something like a react app), you need to deal with a bunch of stupid flags to get the damn browser to even let them go across domains, and a hell of a lot of other annoyances that I can't remember right now.
We are most likely moving to something like JWTs (stored in localstorage or indexeddb) soon because of these issues.
"app.hostname.tld" doesn't need to actually access the cookies at all, it just needs to make requests to "api.hostname.tld" which sets the cookies and then later validates them.
Unfortunately safari blocks this use case unless you have also been to "api.hostname.tld" directly and there doesn't seen to be any easy way around it (outside of allowing all 3rd party cookies...)
And while iOS safari now handles this (i think they allow *.hostname.tld to use 3rd party cookies for any other subdomains as long as hostname isn't a common provider or something?) it doesn't seem to work consistently for UIWebView or WKWebView hybrid applications. And the "allow 3rd party cookies" setting doesn't seem to apply to the web views either.
Of course the server is going to validate it every request, but it's nicer being able to fail "sooner" on the client side when we know we aren't signed in, or we have never signed in, or our token expired a day ago and we need to re-login, etc...
With HTTPOnly cookies we need to make a request to find any of that out, and when paired with redux and react it's very annoying to have to make a web request to get a small glimpse into what the state really is and try and maintain that in a JS value somewhere AND avoid flashes of incorrect state.
Hell with HTTPOnly cookies you can't even clear it without a web request!
My advice is "use proper framework".
(of course you 'can' but I'm not sure if this is recommended or not.)
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.
Kinda like Safari throwing exceptions when you're trying to access localstorage in incognito.
So my comment was in the context of having read both of these. In the link here he also strongly argues against storage of JWT in localStorage.
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 essentially re-implementing something you could be doing in a standard way instead.
Don't you have to do something similar to invalidate tokens anyway?
Then, having the 'just-the-right-amount-of-short-expiration-time' for access token helps... maybe? :)
Not exactly..
1. Invalidation lists can be held in memory easier than an entire token database. And if the invalidation list is huge you can distribute a bloom filter across your nodes and use that to check before hitting the database.
2. As another poster pointed out. Bearer JWT tokens are meant to be short lived. If your implementation is ontop of OAuth use a longer lived refresh token to get a new bearer token every so often (say half an hour). So if you are OK with your invalidated tokens being OK for "up to" the expiry (so up to half an hour in this example) you only need to do strong validation on the refresh tokens.
This makes abusing XSS vulnerabilities to get to the token slightly harder.
But JWT takes care of having the expiry signed in the value (in a cookie the expiry is more of a suggestion that a modified client could ignore). Combine that with low expiry JWT tokens and high expiry refresh tokens (subject to more validation) I think it is a clear winner.
The extra overhead on each request of checking these credentials, especially when these requests are hitting the product's database anyway, are often worth the additional security.
And now there are difficulties around the fact they cannot update an RFC which people will refer to for years.
It's not a vulnerability in one or two libraries - it looks like just about every made the same mistake, which points to something much more broken.
[0] https://auth0.com/blog/critical-vulnerability-in-json-web-en... [1] https://www.ietf.org/mail-archive/web/jose/current/msg05613....
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 already emitted tokens are still valid until their expiration), but it's a good tradeoff for not having server sessions.
JWT tokens have the expiration date embedded in the token. There is no way to force it to expire like you you can with cookies.
Although force is a strong word. Even with cookies if you tell the client to delete a cookie it doesn't mean it has to listen.
Because JSON Web Tokens are short-lived, the blacklist need only contain tokens valid for validity period plus a few seconds and remains very small (often empty).
If you use JWT to allow authorization on several server, then you do need to distribute this blacklist, so it is not a completely trivial solution. In the simplest scenario you might suffice with only maintaining a blacklist on the server that can refresh tokens (this means that when the token expires, a new one cannot be automatically acquired).
Now, you (probably) only absorb the DB hit on blacklisted tokens.
1. As other posters pointed out. The blacklist is probably pretty small and can live in memory on your apps servers. If you have a distributed raft network or something to keep it in sync across nodes, even better.
2. You can avoid checking it against the DB unless the API call is sensitive (example: modifies data).
Oh, and also: "only store a blacklist" does not work if you want to provide the "revoke this app you gave access to a while ago and now it's spamming" functionality like in most social networks.
For me, the log out / cross device session management issue seems to force a pattern of short expiry with self refreshing tokens. Commonly used devices feel always logged in, whereas uncommonly used devices end up needing a fresh log in each time.
0: https://www.chosenplaintext.ca/2015/03/31/jwt-algorithm-conf...
For example -
If some critical part of your app depends on a user's account or session being still valid, just do the check on that endpoint call (grab the sub/ID claim from the JWT and hit the DB, or similar).
The rest of the time - viewing stats/feed/whatever, admit that if the user had a valid token issued to them 5 minutes ago, it's probably OK to send them stats without having to check revocation (or whichever benefit of JWT you're exploiting).
Thing is, this at least gives you the /option/..
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.
Come on. By all means, criticize flawed implementations containing bugs and security holes, but drop the attention-seeking behavior of screaming loudly about how an entire standard is [insert string of superlatives here related to "worthless" and "broken"]. If you're going to make such incredibly strong claims, your arguments had better be up to snuff.
With good implementations (plenty of which exist), and careful usage (via good coding and design habits), JWT is a fine standard and it can save a solid amount of time when constructing the security portions of a system.
Shouting about how something is 100% flawed and should be cast into the flames may get you plenty of views and outrage cred, but (thankfully) it doesn't say much about the veracity of your analysis.
All I see here is the author complaining about poorly implemented JWT libraries. It's not a problem with the spec, it's a problem with the implementation. XML-DSIG suffered from a number of similar issues and was arguably less secure than JWT because of the massive attack surface provided by all the specifications layered on top of each other.
Here's how you can use JWT Safely:
1. Standardize on what's allowed in the alg header and validate it, don't rely on the JWT library you're using to do it for you.
2. Make sure you're using a high quality JWT library, jwt.io keeps a list of JWT implementations and highlights gaps.
3. Understand that bugs in code related to token generation and verification can and lead to compromise of your application and potentially your user's data. Treat such code with great care.
The same problem exists with serialization formats - you have XML and JSON, both of which are standardized and have an "official face", although JSON was not born that way. Google protocol buffers are quite superior in many ways, yet as they are just some product of some company and not an actual standard, decision makers are scared of them.
Technology experts do not get to make all the technical decisions, so standardization matters, even if for the stakeholder feelgood factor!
At the end of the day, tech doesn't win. Developer experience wins. By the time companies have the resources to fight for every iota of performance, they've already won because they shipped product faster than everyone else --- why? Their developers could move and iterate quickly.
Why would an issuer ever let a client decide what algo to use?
"Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key."
Again, under what circumstances would a header be used by the client to ask for a specific implementation?
What about encrypted client side cookies - would you let the client "send a header" to specify which key to use???
The only problems you highlighted are serious input validation issues and a naive, broken trust model.
If these things are suggested in the standard and promptly followed by major implementations, then the standard isn't very good.
https://www.rfc-editor.org/rfc/rfc7518.txt
Still, my point about it missing from RFC7115 stands.
---- Original comment ---------
The standard says you should support NONE as the algorithm and that you should use the algorithm the client sends you, all the while completely failing to mention the issues with that, both in its Security Considerations section (which mentions even more "obvious" things like "use keys with high entropy") and in the description of the algorithm to decode a token (which initial implementers probably relied upon to get to a "correct" implementation). Sorry, that is a failure of the spec as well in my book.
If you spec something with risks, at least mark the critical parts clearly with "point away from foot".
A better standard IMHO would have suggested the API for the decode functions, making it clear that the algorithm used should be whiteli
If you issue tokens with none, then you will have to accept them when clients send them back. This is obviously a very bad idea, but that's all th spec says. If the issuer chooses to be insecure, that is a valid choice.
If you issue tokens with a specific algo, and clients send them back with a different or none header, you know they have been forged.
The spec allows issuers to decide whether to use none, it doesn't say you must trust none tokens if you know you didn't issue them.
A standard promoted as "the standard for secure tokens" should not aim for "You can use the pieces to build a correctly behaving system" or "the spec allows secure implementations", it should aim for "if you use this and follow some spelled-out basic rules you get fool-proof secure tokens" and make wrong usage as hard has possible.
JWT, like SAML, is made to support separate identity providers and the service providers. In the spirit of generality, this means the identity provider(s) could be from a different vendor, operated by a different organization. E.g., you could let users access their account on your service based a token issued from Google. But that means Google chooses the algorithm, not you!
And it's a standard, so you don't have to write any code of your own. Just import the right middleware for your framework and you're set!
So the temptation is there for library authors to support all the defined algorithms, and just enable everything by default to be as compatible as possible - after all, you can just look at the header to see which algorithm to use!
Right, so, why is this in the spec?
Example: The fact that my service has an http stack which must parse a cookie header doesn't mean my app must accept its contents as valid. There's a lot of confusion on this thread about which components should/must do what things.
The approach I use is to have a 'use once' refresh token (long timeout) and a security token (short time out) and JTIs to hold a list of logged out/invalid (refresh token used twice) security token IDs.
Here's what I've never understood about this approach: the browser can send many requests at the same time, over the same (HTTP/2) or different (HTTP/1.1) connections. If, say, six requests hit your backend at the same time, all with the same refresh and security tokens, with four more queued up on the user-agent, and the security token is expired, how do you know:
1. that all ten requests are valid,
2. to revoke the security token once,
3. to generate one new security token,
4. to mark the refresh token as used,
5. to generate one new refresh token?
Is it as simple as granting some leeway on how long the tokens can be used after they expire/are revoked? Do you have some way of serializing requests on the client to prevent this from happening? Or do you assign all ten requests the same "batch" ID and tie them together on the backend somehow? Do you do a preflight request to refresh the security token if it's expired?
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 sign or verify a signature.
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 joinery.
Good modern crypto constructions don't do complicated negotiation or algorithm selection. Look at Trevor Perrin's Noise protocol, which is the transport for Signal. Noise is instantiated statically with specific algorithms. If you're talking to a Chapoly Noise implementation, you cannot with a header convince it to switch to AES-GCM, let alone "alg:none". The ability to negotiate different ciphers dynamically is an own-goal. The ability to negotiate to no crypto, or (almost worse) to inferior crypto, is disqualifying.
A good security protocol has good defaults. But JWT doesn't even get non-replayability right; it's implicit, and there's more than one way to do it. Application data is mixed with metadata (any attribute not in the JOSE header is in the same namespace as the application's data). Anything that can possibly go wrong, JWT wants to make sure will go wrong.
It's 2017 and they still managed to drag all of X.509 into the thing, and they indirect through URLs. Some day some serverside library will implement JWK URL indirection, and we'll have managed to reconstitute an old inexplicably bad XML attack.
For that matter, something crypto people understand that I don't think the JWT people do: public key crypto isn't better than symmetric key crypto. It's certainly not a good default: if you don't absolutely need public key constructions, you shouldn't use them. They're multiplicatively more complex and dangerous than symmetric key constructions. But just in this thread someone pointed out a library --- auth0's --- that apparently defaults to public key JWT. That's because JWT practically begs you to find an excuse to use public key crypto.
These words occur in a JWT tutorial (I think, but am not sure, it's auth0's):
"For this reason encrypted JWTs are sometimes nested: an encrypted JWT serves as the container for a signed JWT. This way you get the benefits of both."
There are implementations that default to compressed.
There's a reason crypto people table flip instead of writing detailed critiques of this protocol. It's a bad protocol. You look at this and think, for what? To avoid the effort of encrypting a JSON blob with libsodium and base64ing the output? Burn it with fire.
I used JWTs because
1. I like the statelessness of JWTs (though I've learnt that there are many trade offs related to this)
2. OAuth uses JWTs, Google uses OAuth, and Google usually know what they're doing
3. I can attach custom claims
4. I don't know of any alternatives, other than x509, which I have less confidence on me being able to validate correctly than JWTs.
What would you suggest? An opaque token which I then look up against a central database/api?
Take a look: https://tools.ietf.org/html/rfc2692 & https://tools.ietf.org/html/rfc2693
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 endpoints.
As for X.509, I agree it kind of sucks but what are the alternatives?
That being said, the aforementioned authenticated channel will more often than not be TLS, which does happen to rely on X.509.
I can agree with your critiques but still wish "real" cryptographers would accept the inevitability of a worse-is-better approach winning here. Don't flip tables, write the jQuery of web crypto. You'll do more good in the long run going with the flow on this one.
The problem is that the browser is not a place where one can safely run crypto.
> Don't flip tables, write the jQuery of web crypto. You'll do more good in the long run going with the flow on this one.
That's a bit like advising a vegan to invent a better method for slaughtering cattle (n.b.: I am not a vegan and have no problem killing & eating animals). The problem is that no-one who understands security thinks that in-browser crypto is a good or safe idea, and thus no-one who understands security wishes to help it along. It should be stopped, not made slightly less bad.
But I admit never thought of it as a particularly bad crypto protocol. It's actually pretty good compared to most negotiable crypto standards out there. I mean, yeah, JWK allows you to embed X.509 (but you don't have to do it), the value of supporting RSA is questionable, their selection of curves is regrettable (but all the world went with the NIST curves), compression on JWE (and not JWS?!) makes me suspicious, and yeah, JSON is kinda verbose compared to MsgPack et al.
But then I remember that before that before JWT came SAML+XML-DSIG (and the whole WS-* ecosystem) and CMS/PKCS#7 (and the whole ASN.1 ecosystem). Ah, compared to these JOSE is a fresh breath of air.
What a lightweight and uncomplicated serialization format - It couldn't even be used for amplified DDOS attacks!
What a modern set of ciphers (besides 'none', sorry, missed that on there ;). No more DES, RC4, or unpopular untested ciphers just there to fill the slots.
Yeah, JOSE still has some parts which are over-engineered but for a STANDARD it's the best one there. Management demands standards, it's a fact of life. And I'd choose JWT over SAML or CMS any day.
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.
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".
Every time I've suggested modifying our JWT implementation to use Ed25519, or using any NaCL implementation for encryption instead of the vulnerability-footgun framework better known as JCE, I get raised eyebrows.
People want standards. Fernet is nice, but it should be pushed to an RFC level and offer more metadata besides a timestamp (not hard, just copy all the JWT claim names in stick a JSON into the ciphertext :))
It's also not useful when you do need asymmetric encryption/signature, and you can't just ignore these use cases, since people will keep JWT alive just for them.
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.
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?
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 sufficient... is there any reason not to just slap a name on that "standard" and publish a bunch of libraries?
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
But there are still cases where you would choose asymmetric signatures over symmetric signature, due to the very essence of it being asymmetric.
The rule of thumb is that when you want to produce a cryptographic token that will be consumed by parties which you don't trust, you should use an asymmetric signature. Realistically speaking, the untrusted party could (and very often should) be almost any other service inside your own company. If you let symmetric keys spread around, you should treat them as good as if they've been leaked.
There is an alternative that if you're able to (and willing to) manage shared secrets through a safe out-of-band channel (e.g. deriving from client secrets).
It was called JWT.
jwt.decode(token, 'secret', algorithms=['HS256'])
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.)
Well.....
It's a pretty good plus, for me: no additional round-trips to the server to grab key user details, which can be put into claims, or check access levels (via roles, permissions, or other types of claim).
This doesn't discount the disadvantages, of course.. I think as with everything it's a case of the right tool for the job. "Depends on the use case".
But, if you're just hiding an additional Delete button on a page based on claims, this comes in handy.
(Edit: in one case, we've used asymmetric keys, i.e. public key so everyone can check integrity. This was a very different use-case to most web apps, though. Overall I'd say if you're carefully checking integrity of something in client-side JS to do something, I think that's probably the wrong approach)
What I like about JWT's concept is it's completely distributed authorisation: there's no call to a central identity provider. Thus a SPA can pull initial security info from its server, and then fire out requests to different APIs. As long as the API endpoints have the SPA server's public key, they can verify everything without calling it or another central server.
Having said that, I'm not able to discern whether it's secure enough to be workable, so I only know to mandate a list of good algorithms on the API endpoints and to use SSL :) I'll have to read about this session stuff.
EDIT: I wonder if in bigger projects, a message bus or in-memory cache could signal a token blacklist once the user logs/times out of the original server? Or as some others have said, just have short expiry times and ping the SPA server for new tokens every couple of minutes.
1. Web client ("offline-first" SPA app) hits HTTPS backend in with username and password
2. Web client receives a a generated API key and secret, which expires in a week/month/whatever.
3. That API key and secret gets stored in localstorage on the client-side by the web app for future use (as long as they're logged in)
4. Web client includes the API key and header in requests to the HTTPS backend of the app.
Of course, there are more specifics that could be added like device fingerprinting, invaliding old web-created tokens when a new one is created, and classifying api keys/secrets to certain devices, but I think those things are ancillary.
This is obviously very very close to what a cookie would be, and the only way I could see it going catastrophically wrong is the browser being compromised (whether the vector is XSS, or some other leaky surface on the user's computer). Regular cookies and JWT have the same issues.
I can't think of a failure mode that's any worse than HTTPS cookies or JWT, and it is dead simple. I've really been trying to find some flaws in that plan lately but I can't.
1. You have to write code to provide the authentication values in all requests.
2. The GET request for the initial page render can't possibly be authenticated.
Why not cookies? Other than that I agree. I really don't see the point of following the JWT spec or using an implementation of it when it has been shown that these implementations are poor (problems with none algorithm & asymmetric keys).
Fundamentally, what we are talking about is simply a claimed identity, verified and signed by your backend. This is a sound principle. Just implement that and your attack surface is considerably smaller.
OWASP says not to do it (https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#L...) but the stated reasons are kind of vague/I'm not sure the reasoning is sound.
If someone has physical access to the machine, all bets are off, and if a XSS vuln happens, pretty sure people can get whatever information they're looking for (including the cookie) anyway. The only real objection was the inability to restrict to HTTPS (path based, everything is just based on same origin regardless of scheme I think), however same origin policy still applies like normal.
I wasn't trying to recommend localstorage over cookies, more like just trying to see if there's any huge blindspot I was missing, everywhere I look says not to do this, but the reasons were never very satisfying.
To be honest though, once there's an unauthorized 3rd party script running on your page, that's a pretty dire already though. I guess it's possible to also protect a little from malicious web addons/extensions though.
I do take issue with the idea that they're not good for stateless authentication: I think they're great when used as short-lived authentication tokens (which don't require serve state) with accompanying long-lived refresh tokens (which do require server state). E.g. a system in which auth tokens are good for an hour and refresh tokens are good for longer (and a refresh token can be refreshed) offer a pleasing user experience (in the normal case, one need never log back on) while also preserving security (revocation takes at most an hour to come into effect). The business gets to make the economic decision about the tradeoffs between risk and cost, deciding whether auth tokens should last for a day, an hour, a minute or a second. I don't think this is 'congratulations, you've reinvented stateful sessions'; rather, it's a well-designed system.
I do wish that JWTs had been better designed, and I wish that folks didn't have to be so careful using the libraries which support them.
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.
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 need to keep the data synchronised in a manner that all 10,000 Docker instances can read/write to it instantly. So instead, a new concept was devised, whereby you use these stateless tokens that don't rely on the same server after issuing.
Of course, it's impossible to invalidate them individually, and they're either insecure (available to JS) or stored in a cookie, and thus sent with every request, which means, due to their larger size than regular session cookies, more data on each request.
So.. that. That is what it's based on.
Edit: added missed word "same".
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?
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.
> 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).
While I agree that it's no longer stateless, JWT's still really useful in terms of not needing a centralised auth/auth provider that everyone has to hit to see if I am who I say I am and whether I'm allowed to call an API. And a message bus is a pretty good compromise between the extremes of big wide systems that share state and microservices that don't talk to anything else.
> Cookies can be set HTTP only ... session cookie. Thanks - I get what you're saying.
> If the data can be read from the network by your JavaScript, it can be read from the network by their JavaScript. Yeah. I think I see what you mean. Assuming you don't mean literally "reading data from the network", as I assume the problem isn't the network access but the access to the security info, are you saying that hostile Javascript on the page can read everything and call everything that legitimate Javascript can?
If so, I can't tell the difference between that and - say - a CSRF token, which presumably can also be read by "their" Javascript? How does anything work if you have that mentality?
The vast majority of people don't need the scale that is difficult to achieve with regular server-side sessions, and that JWT claims to "solve". They add complexity to solve a problem most people don't have.
> I can't tell the difference between that and - say - a CSRF token, which presumably can also be read by "their" Javascript
CSRF is about e.g. making a user's browser make a form submission that results in a request which is malicious in some way. CSRF Tokens are embedded in each legitimate form to ensure that the submission received came from a form you control.
If the attacker has JavaScript access to your page, CSRF is not your problem, so CSRF tokens can't help you.
Not really talking about sessions, but I think I see what you're saying.
> If the attacker has JavaScript access to your page, CSRF is not your problem, so CSRF tokens can't help you.
I agree. I'm trying to understand what you were saying about whatever your Javascript has access to, their Javascript does as well. Why should this be a criticism of JWT and not CSRF?
Well, mostly a JWT lets you know the user that is signed in.
A server-side session generally does the same thing, but can be used to store larger amounts of data.
> I'm trying to understand what you were saying about whatever your Javascript has access to, their Javascript does as well. Why should this be a criticism of JWT and not CSRF?
They're unrelated attack vectors.
CSRF is about bad actors producing links and/or forms on a different site to your own, that a legitimate user clicks/submits (either through social engineering or some kind of javascript in their page) causing them to make a request to your server. A CSRF token prevents this because it ensures that form submission requests have come from a form hosted on your server.
In the situation where we're worried about what someone else's JavaScript has access to, it means their javascript is already loaded into your page: a vulnerability with poorly escaped user content, a rogue browser extension, a malicious or compromised CDN, etc.
In that situation, CSRF is irrelevant. The CS in CSRF is "Cross Site" - this is no longer cross site, as the script is running in the context of your own page.
So in this situation nothing we do can prevent them from making requests within the current user session.
But what we can prevent them from doing, is stealing a user identifying token: e.g. a session cookie, by marking it HTTP Only, so the JS environment doesn't see it.
JWT's accessed over XHR/etc and stored in local storage are available to any malicious scripts running, meaning they can grab the user's JWT and send it off to their own server, allowing them to make requests as the user.
If you send JWT's as cookies and mark them as HTTP only, you've defeated the "don't send session cookies with every request" goal of JWT, and the cookie will be bigger than most session cookies.
> They're unrelated attack vectors. Good point. I guess I more just meant that what can malicious Javascript do with endpoints protected by JWT that it can't do with endpoints protected another way.
> JWT's accessed over XHR/etc and stored in local storage are available to any malicious scripts running, meaning they can grab the user's JWT and send it off to their own server, allowing them to make requests as the user.
I guess this answers the above question: the difference isn't in what can be executed in the browser, but what can be shipped to a different server to be used in attacks from there.
To mitigate that, then, how's this setup:
1) User's session is maintained in HTTP-only cookies. 2) Browser can use (1) to request a JWT token (and a refresh key) to hit a 3rd-party API endpoint. The token is valid for 5 minutes. 3) Browser can use the refresh key from (2) to request another JWT token.
Does that pretty much bring it up to parity with using cookies everywhere, while keeping the goal of noncentral auth/auth?
https://github.com/conjurinc/slosilo#signing
We use this library to store a signed username. Nothing more than that, just a username in a signed, expiring token. No `alg` field or any other options.
The Slosilo code has been subjected to a professional crytographic audit, so it's safe for you to use. Unfortunately, without an NDA, we can't show you the audit report, that's just how these things work. The only audit finding was a recommendation that we switch to `AES-256-GCM`, which we did in Slosilo 2.0, November 2014.
Auth doesn't have to be complicated to be effective.
Developers know/care very little about information security and a lot about following "standards" and "best practices."
Google and Facebook have learned over the years to take advantage of this.
In what way?
There's also generally a lot of FUD around authentication because most web developers don't understand information security well enough to weigh the pros and cons, so technical discussions usually devolve into, "Google uses it, so it must be solid."
[1] https://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-...
> Just use cookies over HTTPS.
Maybe it's because of my experience working in environments where cookies were disabled but I just try to avoid them where possible nowadays for my authentication handling. Instead of storing the equivalent of a session / token id in a cookie I just store it in sessionStorage and include that in requests.
Trading in one security issue for another makes no sense. Just implement the correct mitigation against CSRF attacks; namely, CSRF tokens.
Which is precisely what the blog post that was hyperlinked in the sentence you were responding to was advocating.
If you can show ReactJS XSS then I may need to reconsider.
It hasn't quite convinced me.
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.
It seems to be scheduled for implementation in several clients [1].
[0]: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13
Given that tokens are signed and you can't really unwrap them on the client side without having "more information", I'd say this article is long on scare-tactics and short on real-life usage scenarios.
* Transport: how the session ID or token is shipped between clients and servers (authorization header, cookie headers, or payload).
* Storage: how the session ID or token is stored on clients (cookies, localStorage, sessionStorage, or in memory).
* Statefulness: whether to use a stateless token (with or without a revocation list) or a stateful, server-side session.
* Encryption and/or signing
* Structure/standardization
Examples:
* JWT generates structured, stateless tokens that are signed—and optionally encrypted (JWE)—with the implementor's choice of algorithm. The tokens can be transported and stored by any mechanisms.
* Rack::Session::Cookie (in Ruby) generates unstructured, stateless tokens that are signed—not encrypted—with HMAC. The tokens are transported and stored as cookies.
* Rack::Session::Pool (also in Ruby) maintains an in-memory store of unstructured, stateful sessions. Unsigned and unencrypted session IDs are transported and stored as cookies.
The point being that you can really mix and match. You can even send a session ID in a header and store it as a non-HttpOnly-cookie on the client. Anything goes!
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.
> JSON Web Signatures Makes Forgery Trivial
> 1. Send a header that specifies the "none" algorithm be used
Most JWT libraries require you to explicitly allow the none algorithm. I had to set a very explicit system property to even get the library I am using to accept none! Even so, anyone implementing JWT should make sure that only the algorithms actually used are accepted.
> 2. Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key.
Being able to use the public RSA key used to sign an RS256 JWT as the key for a (forged) HS256 token requires the server to accept both RS256 and HS256, and (critically) to be able to use a key configured for RSA assymetric signing to validate HMAC SHA256 signatures. I have not been able to reproduce this latter bug with the library I am using, but even if it did, I still check the algorithm field beforehand: if a token claims it is HS256 signed, I use the (private) key configured for that (if HMAC SHA256 signing is allowed in my application); if it is RS256 signed, I use the (public) key configured for that. The library I use doesn't even get a choice in this; it either receives a JWT that claims to be RS256 together with a RSA 2048 public key, or it gets a JWT that claims to be HS256 together with a private signing key exlcusively used for HS256.
The code preforming those checks between the REST-call receiving the JWT and the JWT library is trivial.
This is all assuming that you would place a service configured to accept both HS256 and RS256 tokens at the same time in production.
As with any security standard: don't use crap libraries; do your research; test your service for common vulnarabilities; follow recommendations made by experts; and don't deploy techniques you don't quite grasp in production software.
> JSON Web Encryption is a Foot-Gun
So is TLS, or hashing passwords. Security is hard and requires a lot of reading and grokking (but it is not too hard for any moderately experienced software engineer).
> TL;DR
Really? 'Too long; didn't read' for a handful of paragraphs? I'll grant the author this much; anyone who can't muster the attention span to read that much text without groping around for a single sentence summary shouldn't be implementing (any!) security standards.
JSON Web Token is a well-documented accessible security standard with a lot of comprehensive information available. As with any technique, there are caveats, but these caveats do not discredit the technique as a whole.
The leak of a JWT secret allows for easier and more severe attacks than the leak of many other secrets.
Checking against a blacklist / some secondary measure may only be required for important actions such as changing password, checking out, etc.
I've been using headerless JWTs for stateless API authentication and authorization (JWT without the first segment), but the work is preliminary and I wonder if I'm doing it wrong.
* 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])
payload = { sub: @user.id, exp: Time.now.to_i + 1_209_600 }
cookies[:remember_me] = JWT.encode(payload, 's3Krit', 'HS256')
2. it doesn't, internal session class does and IMO most apps do not need expire claim.
3. Just put issuer/issued_at/whatever in your object
4. I suggest to look at messageverifier and do your own (and use sha256 hmac). Why? Lets consider 50 lines of code not "maintaining your crypto fork" but merely helpers.
5. JWT has more LOC inside, say header payload is just useless. I believe having OpenSSL::HMAC helpers is better and simple enough to not do it wrong
> 2. it doesn't, internal session class does and IMO most apps do not need expire claim.
If you're generating a token to send to an SPA or native app, you can't rely on any other expiration mechanism. It needs to be embedded in the token or stored server-side in a database-backed session or what have you.
> 3. Just put issuer/issued_at/whatever in your object
You're missing the point that these features would require additional SLOC to verify the "claims."
> 4. I suggest to look at messageverifier and do your own (and use sha256 hmac). Why? Lets consider 50 lines of code not "maintaining your crypto fork" but merely helpers.
By this logic, ruby-jwt isn't crypto, just helpers. It seems to be frowned upon simply because it includes additional features some people may not need, and those features and alternative signing methods require more SLOC than your presumed "optimal" implementation. Do you see no value in a flexible, reusable library?
> 5. JWT has more LOC inside, say header payload is just useless. I believe having OpenSSL::HMAC helpers is better and simple enough to not do it wrong
How can critics justify the position that people should write their own OpenSSL::HMAC helpers because they can't correctly call the JWT helpers?
Well that's got me convinced, compelling argument old chap.
> and don't scale.
The vast majority of developers in the world are never going to actually need the type of scalability that requires stateless tokens for authentication.
What else are we going to use? JWT is basically the simplest token protocol possible that maintains antiforgery properties. It's great that somebody standardized something that most API's were using anyways. If you give anyone that knows crypto the task of making a simple token protocol they will come up with JWT over and over.