22 ms·

JSON Web Tokens should be avoided

386 points by CiPHPerCoder 10y ago

BinaryIdiot 10y ago
Well how about that; I had no idea there was a specific standard for this type of thing nor did I realize the client could specifically request a type of algorithm to be used. That seems incredibly short sighted; why wouldn't you let the server handle that and make the algorithm completely transparent? > 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.
- andy_ppp 10y ago
  Yes, this prevents CSRF without tokens too.
  - joepie91_ 10y ago
    ... and causes another security issue in the process, namely the ability to steal session credentials after an XSS attack. Trading in one security issue for another makes no sense. Just implement the correct mitigation against CSRF attacks; namely, CSRF tokens.
    - andy_ppp 10y ago
      Yes but you can now concentrate make yourself XSS proof right; with an XSS you can still get someones cookies... unless you are talking HttpOnly. But we are probably talking single page webapps here anyway.
      - CiPHPerCoder 10y ago
        > unless you are talking HttpOnly Which is precisely what the blog post that was hyperlinked in the sentence you were responding to was advocating.
        andy_ppp 10y ago
        If there are no XSS attacks against ReactJS then both ways protect me from both CSRF and XSS right? If you can show ReactJS XSS then I may need to reconsider.
iofiiiiiiiii 10y ago
It would really help encourage the uptake of better alternatives like libsodium if it were standardized. Just referencing some random library can scare decision makers; whereas referencing an IETF official document or ISO standard makes them just take it as given. 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!
- keithwhor 10y ago
  ... yes, but... sidenote, JSON is almost unreasonably easy to grok, and translates well into every web-abstracted language, making it the clear-and-away winner. 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.
- deleted 10y ago
  [deleted]
dorianm 10y ago
It depends on the security model, but in the long term I think sessions are the way to go. It becomes much easier to differentiate the different clients that connects to the API
forgottenacc57 10y ago
This post says "it's insecure if you do it wrong". Well.....
- keithwhor 10y ago
  I hear where you're coming from... but this is also the bane of developer existence. We all have to accept that, every year, tens of thousands of new developers looking for jobs enter the market. There's such a demand for developers that these people get jobs. So footguns, as much as we like to play high-and-mighty and say, "well, duh, don't shoot yourself in the foot" are a real, existential risk to a lot of companies.
  - true_religion 10y ago
    I was under the impression that newly minted developers would use existing libraries and frameworks, which have already take security into account.
    - saint_fiasco 10y ago
      The article points out that many popular libraries have vulnerabilities and unsafe defaults.
      - lostcolony 10y ago
        Which to me says that relying on there not being any footguns is wishful thinking. The better recourse, to my mind, is to stress the need for mentorship, so people learn to proactively look out for traps.
- detaro 10y ago
  A standard that best case doesn't explain the risks properly (so many implementers get it wrong) and worst case prescribes dangerous behavior isn't a very good standard. Especially in a field where many developers are told over and over again to rely on standards, it really should spell out even tiny issues.
fcvarela 10y ago
"Send a header that specifies the "none" algorithm be used" 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.
- deleted 10y ago
  [deleted]
- detaro 10y ago
  > 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.
  - StreamBright 10y ago
    But they aren't. Nobody is suggesting to anybody to use NONE as the algorithm.
    - detaro 10y ago
      EDIT: the secondary spec describing the algorithms is at least clear on the use of none, I missed that at first: Implementations that support Unsecured JWSs MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to not be integrity protected. Implementations MUST NOT accept Unsecured JWSs by default. https://www.rfc-editor.org/rfc/rfc7518.txt 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
jacopofar2 10y ago
The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header (https://github.com/auth0/node-jsonwebtoken/blob/master/verify.js#L72 https://github.com/auth0/node-jsonwebtoken/blob/master/verif...) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your already emitted tokens are still valid until their expiration), but it's a good tradeoff for not having server sessions.
- StreamBright 10y ago
  Exactly. The session invalidation has to happen using a session store or expiry header or something similar. In this regard JWT is not better than cookies.
  - throwaway2016a 10y ago
    > expiry header 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.
- Freak_NL 10y ago
  Session invalidation is possible though, by maintaining a (short) blacklist of tokens on the server. JSON Web Tokens can be given an ID (via the jti claim), and server-side these IDs can be matched against this blacklist. When you log out, you send a request to the service that your current token be blacklisted. 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).
homakov 10y ago
JWT is bad, signed tokens are fine. Session cookies suck and don't scale. Just copy code of MessageVerifier from Rails, it's simple.
- theprotocol 10y ago
  Can you elaborate on your first sentence? 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.
- digitalpacman 10y ago
  He didn't say use SESSIONS, he said use COOKIES for the data you would expect to go within a session. They scale just fine. You shouldn't be storing that much data in a JWT either.
- kierenj 10y ago
  A JWT is a signed token - or at least, in most cases, is?
  - homakov 10y ago
    JWT is a subset of signed tokens, but using home baked signed token is still great.
- mwpmaybe 10y ago
  * MessageVerifier defaults to SHA1. That hasn't been a good default for a few years now. * 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]) But this is "bad": payload = { sub: @user.id, exp: Time.now.to_i + 1_209_600 } cookies[:remember_me] = JWT.encode(payload, 's3Krit', 'HS256') They seem fairly equivalent to me?
Freak_NL 10y ago
I would have expected a more in-depth analysis of JWT compared to other techniques. As much as I appreciate the effort to warn people away from bad security practices, JWT is not as a technique fundementally broken. > 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.
StreamBright 10y ago
>> 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.
- jondubois 10y ago
  Agreed, the author of the article shouldn't point out a few flaws/bugs that some JWT libraries had in the past and then deduce that the whole standard is broken at a fundamental level. JWT is not designed to hold sensitive data, it's designed to hold non-sensitive authentication information like usernames, access groups, privilege levels, and other similar non-sensitive identifying information. It's useful because it loosens your reliance on back-end memory stores like Redis to track session data and makes your architecture much cleaner/simpler.
- stephenr 10y ago
  > 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 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".
  - robertlagrant 10y ago
    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?
idkfa 10y ago
So JWT is bad because there are bad implementations and there are dumb people who shoot their feet^W^W^Wdon't force alg. Seems like doing software development for 13 years leads to serious problems with logic. There is also confusion between sessions and session storage. Meh..
kierenj 10y ago
One advantage I think not mentioned by some of the linked articles is that the JWT's claims are readable on the client. 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".
- arethuza 10y ago
  Out of interest, do you check the authenticity and integrity of the JWT on the client side?
  - kierenj 10y ago
    We provide an endpoint to check validity with the server, but haven't used it too often. Anything "reasonably sensitive" (or more) doesn't depend on anything like this client-side security. 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)
    - Freak_NL 10y ago
      That's exactly what is useful for. Of course access to a resource is determined server-side; JWT simply allows you to adjust the UI to the permissions the user has without any additional calls. If the user changes the JWT he has client-side, he will just get a broken delete button (the server will reject a JWT that has been tampered with).
  - deleted 10y ago
    [deleted]
- mattmanser 10y ago
  You've already been to the server once, if you terri-bad app design requires you to go twice that's more your problem than a "feature" of a broken session system.
jlebrech 10y ago
JWT can help make a system look more secure, for example you store userid, email some token in session store and a customer goes poking around and tells everyone that he can see that inside the inspector (his data), if you obfuscate it with JWT you eliminate false positives but it doesn't make it anymore secure.
awjr 10y ago
I'm really confused by this post, a signed JWT is issued by the identity provider (or API end point) and is then validated again by the API end point when part of an API call, usually as a bearer token in the header. The validation of the signed JWT is done via the API. 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.
- mwpmaybe 10y ago
  > 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?
tboyd47 10y ago
JWT is to HTTP Basic what OAuth2 is to logging in. 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.
- peletiah 10y ago
  > Google and Facebook have learned over the years to take advantage of this. In what way?
  - tboyd47 10y ago
    If authentication is too complicated for the average developer to understand, other businesses will become more willing to use Goog & FB as identity providers. 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."
esseti 10y ago
So, what should one should use then? However, It's insecure with a bad client, right? Beacuse I was going to use http+JWT for microservices communication an internal network, would that be a problem? any tips on what to switch?
- Freak_NL 10y ago
  JWT is fine. Just lock down the library you chose as much as possible (only accept one algorithm for instance).
floatboth 10y ago
"Just use cookies over HTTPS [instead of JWT]" is weird advice. I mean, JWT goes… inside… things like cookies. (or the Authorization header in APIs, of course)
- mwpmaybe 10y ago
  This drives me nuts. To expand on your point, there are a number of separate, debatable design decisions that seem to get conflated all the time: * 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!
camdenlock 10y ago
Oh my god! Outrage! Superlatives! 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.
jamespo 10y ago
Token invalidation being an issue depends on the app. Checking against a blacklist / some secondary measure may only be required for important actions such as changing password, checking out, etc.
technion 10y ago
A lot of people are talking about the "none" algorithm issue, but the more recent vulnerability[0] is more telling: The report to the working group mailing list[1] led to the point that the standard had a "security considerations" section in the RFC, and this particular issue was never covered. 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-encryption https://auth0.com/blog/critical-vulnerability-in-json-web-en... [1] https://www.ietf.org/mail-archive/web/jose/current/msg05613.html https://www.ietf.org/mail-archive/web/jose/current/msg05613....
fareesh 10y ago
I use JWT in a couple of projects and it never once occurred to me to let the client decide the algorithm. I am not sure what use-case would necessitate something like that.
- draw_down 10y ago
  Guess that shouldn't be in the spec then.
akfish 10y ago
I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT. All I am getting is "JWT can be misused in such such way that makes your application vulnerable. And neither its standards nor libraries prevent that, so it sucks". But when is the last time we see any technology successfully prevented people from being silly?
- ponytech 10y ago
  I agree. I've read the whole article and still wonder why I should stop using JWT.
  - slau 10y ago
    You shouldn't. Simply check that the hash algorithm specified by the client is the one you used when issuing the token. In a side project, I simply hard code the algorithm [1]. [1]: https://github.com/teotwaki/grace-calendar/blob/develop/app/helpers/jwt.rb https://github.com/teotwaki/grace-calendar/blob/develop/app/... Edit: DYAC.
- RegEx 10y ago
  https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228
- nallerooth 10y ago
  +1. I read the article and ended up with a TLDR where I expected some explanation and facts. It's a good thing that cookies have never been used in a bad manner. /sarcasm
- sgift 10y ago
  > But when is the last time we see any technology successfully prevented people from being silly? 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.)
- 10y ago
scandox 10y ago
I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). 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.
- Klathmon 10y ago
  If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not 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.
  - 10y ago
regecks 10y ago
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 sign or verify a signature.
- tptacek 10y ago
  I agree. The OAEP thing was weird.
  - yuhong 10y ago
    In fact, JWE and JWS are not as flawed as JWT is, right? ACME uses JWS.
Dowwie 10y ago
What I've gathered from this post is that the tech community ought to spend more time promoting JWT best practices because misuse can lead to bad times
andy_ppp 10y ago
Lock the encryption to RS512 and the standard is fine. I do a test against that and I also include a key relevant to and content I send with the token. This make the signature per request and considerably more difficult to forge. Maybe using JWTs for sessions is bad, using them for APIs is awesome with the specific caveats.
brutuscat 10y ago
Should we use Hawk + Oz[1]? [1] https://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-an-oauth-replacement/ https://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-...
robertlagrant 10y ago
Is using none a bit like using http instead of https? The standards support it, but it's 2017 so we shouldn't do it. 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.
hardwaresofton 10y ago
Can anyone think of some criticism for simply storing an API key and secret in localstorage for a web client? It's 50% bridging the gap between using cookies and a normal API and 50% simplifying frontends. The scheme I'm currently using on a project goes like this: 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.
- mkohlmyr 10y ago
  Perhaps I am missing something but I really don't see the point of storing it in localStorage or sessionStorage over cookies what so ever. 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.
  - hardwaresofton 10y ago
    The reason I wanted to try this scheme was to finally remove the little difference in authentication method between web frontend and commandline/mobile API client... OWASP says not to do it (https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage_.28a.k.a._Offline_Storage.2C_Web_Storage.29 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.
StevePerkins 10y ago
The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any 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.
- tptacek 10y ago
  I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, 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.
asanso 10y ago
The author of http://blog.intothesymmetry.com/2017/03/critical-vulnerability-in-json-web.html http://blog.intothesymmetry.com/2017/03/critical-vulnerabili... here FWIW. Personally I would not be so drastic. JOSE per se is not too bad (at least the idea is cool). Some crypto choices though have been really arguable...
- tptacek 10y ago
  That post is great work. Thanks again. But I think you're wrong about JWT. 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.
cashy 10y ago
feels like a troll piece
deleted 10y ago
[deleted]
ohstopitu 10y ago
so if JWTs are supposed to be avoided, what's a better alternative? cookies? (does that not open another can of worms?)
lucb1e 10y ago
This article jumps straight from introduction to conclusion. Like, "there have been big issues in the past and the available algorithms are questionable because [missing part] so don't use it". It hasn't quite convinced me.
Kiro 10y ago
OT but I need a wake-up call here. Upon login I'm sending back a generated UUID tied to the account and saves it as a cookie in the client. What's wrong with this approach?
- russtrotter 10y ago
  That approach is generally how many web platforms do their server-side session management. As with anything that is more or less home-grown (vs using that platform session implementation), you'll want to ask yourself: 1) how easy can my UUID be spoofed? 2) can i revoke/invalidate/logout my UUID session
- davewritescode 10y ago
  The only problem I can see is that depending on how you're generating the UUID you might be providing UUIDs that are guessable by a 3rd party.
pweissbrod 10y ago
Title misleading: JSON Web tokens should be avoided <FOR PASSING TO THE USER AS A SESSION KEY>
tfuqua 10y ago
When creating Universal JS apps, I usually store a user token as a cookie vs. local storage. I don't think you can server-side render content if you're using local storage.
davewritescode 10y ago
This article is slightly misleading. One should ALWAYS be suspect of any article that states X is always bad and should be avoided. Google, Facebook, Microsoft and hundreds of other companies are using JWT in security critical software. If you've ever logged into an app with Google, you've used JWT. 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.
mamoulian 10y ago
I suspect there are developers out there who haven't kept their secret as secret as it ought to be. The leak of a JWT secret allows for easier and more severe attacks than the leak of many other secrets.
tlrobinson 10y ago
For my current use-case, one of the appealing things about JWT is there are libraries for just about every language, which makes it easy for 3rd party developers to integrate with my service. Are there any better alternatives to JWT that have implementations in many languages? If not, elsewhere in this thread tptacek and others have suggested essentially `base64_encode(crypto_auth(json_encode(object)))` would be sufficient... is there any reason not to just slap a name on that "standard" and publish a bunch of libraries?
- ash 10y ago
  I was confused about libsodium/NaCl APIs, specifically crypto_sign vs crypto_auth. The difference: 1. `crypto_auth` is for secret-key signatures (auth): https://download.libsodium.org/doc/secret-key_cryptography/secret-key_authentication.html 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/public-key_signatures.html 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 https://news.ycombinator.com/item?id=13866983
  - unscaled 10y ago
    Symmetric signature is simpler, leaner (in message size overhead), faster and more secure (by virtue of it being simpler). 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).
- deathanatos 10y ago
  > is there any reason not to just slap a name on that "standard" and publish a bunch of libraries? It was called JWT. jwt.decode(token, 'secret', algorithms=['HS256']) That's the Python for JWT; encode is similar. You can try something like what you suggest, but the devil is in "object": want your token to expire after a finite amount of time? You'll need to encode that yourself. Token need to be valid only for certain cases? You'll need to encode that yourself. Essentially, you end up reinventing the part of JWT that is relevant to your use-case, and hopefully, arrive at a decent API. At least in Python, python-jose's APIs will check not only the signature, but these additional claims (expiration of the token, that the token is applicable to the use we're verifying it for). (I still think we should be moving towards a common API (and JWT is good enough) and building libraries around that standard. They're going to fall short in some ways at first, and I wish people would help improve them. The suggestion of using base64/libsodium feel dangerously close to "rolling your own", because its too low-level for the purpose at hand.)
jchw 10y ago
Their suggestion to use secret_box is dangerous. It neglects to mention you still need to MAC the content, lest you leave open malleability attacks.
ChicagoDave 10y ago
Except for the fact that JWT's are fairly ubiquitous at this point. Depending on the needs of an API, the timeout is the big point. Banking apps generally timeout pretty quickly...as in 30-60 seconds. Mobile apps vary in how long a token stays valid, but many keep it short. 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.
zeveb 10y ago
I think that JSON Web Tokens (like most things involving JSON) are ill-thought-out, and they can definitely be a bit of a foot-gun, but they are also useful. 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.
throwawaysed 10y ago
This article has little substance. The arguments don't apply to JWT, it just mentions badly done implementations and an insecure option that obviously nobody would turn on. 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.
alejogutierrez 10y ago
This is my opinion about the article: 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.
kgilpin 10y ago
If you are interested in a Ruby library for signing and verifying a token containing a simple payload, take a look at our Slosilo library: https://github.com/conjurinc/slosilo#signing 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.
tracker1 10y ago
Personally, I've hand-written a few JWT implementations, and usually avoid even using a few of the "standards" often avoiding even reading the header. This is because usually I've used them for internal systems calling other systems. If you avoid reading the header, and have standard policy on signatures, combined with very short lived tokens (max 1m) combined with https, there is minimal risk. Yes, the standard is flawed, that doesn't mean the structure is inherently bad, or that using said design is bad by itself.
cdelsolar 10y ago
No they shouldn't, and stop spreading FUD. First of all, the headline has a blanket statement that they should be avoided, whereas the article says don't use them for sessions (which I agree with). There are many other uses for JWT that aren't sessions. The vulnerabilities the article brings up were quickly patched in all major libraries quite a while ago.
hdhzy 10y ago
Can anyone comment if TLS Token Binding [0] does solve some subset of problems usually solved with JWT? It seems to be scheduled for implementation in several clients [1]. [0]: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13 https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13 [1]: https://www.chromestatus.com/feature/5097603234529280 https://www.chromestatus.com/feature/5097603234529280

386 points by CiPHPerCoder 10y ago

Well how about that; I had no idea there was a specific standard for this type of thing nor did I realize the client could specifically request a type of algorithm to be used. That seems incredibly short sighted; why wouldn't you let the server handle that and make the algorithm completely transparent? > 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.

andy_ppp 10y ago
Yes, this prevents CSRF without tokens too.
- joepie91_ 10y ago
  ... and causes another security issue in the process, namely the ability to steal session credentials after an XSS attack. Trading in one security issue for another makes no sense. Just implement the correct mitigation against CSRF attacks; namely, CSRF tokens.
  - andy_ppp 10y ago
    Yes but you can now concentrate make yourself XSS proof right; with an XSS you can still get someones cookies... unless you are talking HttpOnly. But we are probably talking single page webapps here anyway.
    - CiPHPerCoder 10y ago
      > unless you are talking HttpOnly Which is precisely what the blog post that was hyperlinked in the sentence you were responding to was advocating.
      - andy_ppp 10y ago
        If there are no XSS attacks against ReactJS then both ways protect me from both CSRF and XSS right? If you can show ReactJS XSS then I may need to reconsider.

iofiiiiiiiii 10y ago

It would really help encourage the uptake of better alternatives like libsodium if it were standardized. Just referencing some random library can scare decision makers; whereas referencing an IETF official document or ISO standard makes them just take it as given. 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!

keithwhor 10y ago
... yes, but... sidenote, JSON is almost unreasonably easy to grok, and translates well into every web-abstracted language, making it the clear-and-away winner. 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.
deleted 10y ago
[deleted]

dorianm 10y ago

It depends on the security model, but in the long term I think sessions are the way to go. It becomes much easier to differentiate the different clients that connects to the API

forgottenacc57 10y ago

This post says "it's insecure if you do it wrong". Well.....

keithwhor 10y ago
I hear where you're coming from... but this is also the bane of developer existence. We all have to accept that, every year, tens of thousands of new developers looking for jobs enter the market. There's such a demand for developers that these people get jobs. So footguns, as much as we like to play high-and-mighty and say, "well, duh, don't shoot yourself in the foot" are a real, existential risk to a lot of companies.
- true_religion 10y ago
  I was under the impression that newly minted developers would use existing libraries and frameworks, which have already take security into account.
  - saint_fiasco 10y ago
    The article points out that many popular libraries have vulnerabilities and unsafe defaults.
    - lostcolony 10y ago
      Which to me says that relying on there not being any footguns is wishful thinking. The better recourse, to my mind, is to stress the need for mentorship, so people learn to proactively look out for traps.
detaro 10y ago
A standard that best case doesn't explain the risks properly (so many implementers get it wrong) and worst case prescribes dangerous behavior isn't a very good standard. Especially in a field where many developers are told over and over again to rely on standards, it really should spell out even tiny issues.

fcvarela 10y ago

"Send a header that specifies the "none" algorithm be used" 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.

deleted 10y ago
[deleted]
detaro 10y ago
> 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.
- StreamBright 10y ago
  But they aren't. Nobody is suggesting to anybody to use NONE as the algorithm.
  - detaro 10y ago
    EDIT: the secondary spec describing the algorithms is at least clear on the use of none, I missed that at first: Implementations that support Unsecured JWSs MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to not be integrity protected. Implementations MUST NOT accept Unsecured JWSs by default. https://www.rfc-editor.org/rfc/rfc7518.txt 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

jacopofar2 10y ago

The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header (https://github.com/auth0/node-jsonwebtoken/blob/master/verify.js#L72 https://github.com/auth0/node-jsonwebtoken/blob/master/verif...) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your already emitted tokens are still valid until their expiration), but it's a good tradeoff for not having server sessions.

StreamBright 10y ago
Exactly. The session invalidation has to happen using a session store or expiry header or something similar. In this regard JWT is not better than cookies.
- throwaway2016a 10y ago
  > expiry header 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.
Freak_NL 10y ago
Session invalidation is possible though, by maintaining a (short) blacklist of tokens on the server. JSON Web Tokens can be given an ID (via the jti claim), and server-side these IDs can be matched against this blacklist. When you log out, you send a request to the service that your current token be blacklisted. 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).

homakov 10y ago

JWT is bad, signed tokens are fine. Session cookies suck and don't scale. Just copy code of MessageVerifier from Rails, it's simple.

theprotocol 10y ago
Can you elaborate on your first sentence? 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.
digitalpacman 10y ago
He didn't say use SESSIONS, he said use COOKIES for the data you would expect to go within a session. They scale just fine. You shouldn't be storing that much data in a JWT either.
kierenj 10y ago
A JWT is a signed token - or at least, in most cases, is?
- homakov 10y ago
  JWT is a subset of signed tokens, but using home baked signed token is still great.
mwpmaybe 10y ago
* MessageVerifier defaults to SHA1. That hasn't been a good default for a few years now. * 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]) But this is "bad": payload = { sub: @user.id, exp: Time.now.to_i + 1_209_600 } cookies[:remember_me] = JWT.encode(payload, 's3Krit', 'HS256') They seem fairly equivalent to me?

Freak_NL 10y ago

I would have expected a more in-depth analysis of JWT compared to other techniques. As much as I appreciate the effort to warn people away from bad security practices, JWT is not as a technique fundementally broken. > 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.

StreamBright 10y ago

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

jondubois 10y ago
Agreed, the author of the article shouldn't point out a few flaws/bugs that some JWT libraries had in the past and then deduce that the whole standard is broken at a fundamental level. JWT is not designed to hold sensitive data, it's designed to hold non-sensitive authentication information like usernames, access groups, privilege levels, and other similar non-sensitive identifying information. It's useful because it loosens your reliance on back-end memory stores like Redis to track session data and makes your architecture much cleaner/simpler.
stephenr 10y ago
> 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 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".
- robertlagrant 10y ago
  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?

idkfa 10y ago

So JWT is bad because there are bad implementations and there are dumb people who shoot their feet^W^W^Wdon't force alg. Seems like doing software development for 13 years leads to serious problems with logic. There is also confusion between sessions and session storage. Meh..

kierenj 10y ago

One advantage I think not mentioned by some of the linked articles is that the JWT's claims are readable on the client. 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".

arethuza 10y ago
Out of interest, do you check the authenticity and integrity of the JWT on the client side?
- kierenj 10y ago
  We provide an endpoint to check validity with the server, but haven't used it too often. Anything "reasonably sensitive" (or more) doesn't depend on anything like this client-side security. 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)
  - Freak_NL 10y ago
    That's exactly what is useful for. Of course access to a resource is determined server-side; JWT simply allows you to adjust the UI to the permissions the user has without any additional calls. If the user changes the JWT he has client-side, he will just get a broken delete button (the server will reject a JWT that has been tampered with).
- deleted 10y ago
  [deleted]
mattmanser 10y ago
You've already been to the server once, if you terri-bad app design requires you to go twice that's more your problem than a "feature" of a broken session system.

jlebrech 10y ago

JWT can help make a system look more secure, for example you store userid, email some token in session store and a customer goes poking around and tells everyone that he can see that inside the inspector (his data), if you obfuscate it with JWT you eliminate false positives but it doesn't make it anymore secure.

awjr 10y ago

I'm really confused by this post, a signed JWT is issued by the identity provider (or API end point) and is then validated again by the API end point when part of an API call, usually as a bearer token in the header. The validation of the signed JWT is done via the API. 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.

mwpmaybe 10y ago
> 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?

tboyd47 10y ago

JWT is to HTTP Basic what OAuth2 is to logging in. 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.

peletiah 10y ago
> Google and Facebook have learned over the years to take advantage of this. In what way?
- tboyd47 10y ago
  If authentication is too complicated for the average developer to understand, other businesses will become more willing to use Goog & FB as identity providers. 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."

esseti 10y ago

So, what should one should use then? However, It's insecure with a bad client, right? Beacuse I was going to use http+JWT for microservices communication an internal network, would that be a problem? any tips on what to switch?

Freak_NL 10y ago
JWT is fine. Just lock down the library you chose as much as possible (only accept one algorithm for instance).

floatboth 10y ago

"Just use cookies over HTTPS [instead of JWT]" is weird advice. I mean, JWT goes… inside… things like cookies. (or the Authorization header in APIs, of course)

mwpmaybe 10y ago
This drives me nuts. To expand on your point, there are a number of separate, debatable design decisions that seem to get conflated all the time: * 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!

camdenlock 10y ago

Oh my god! Outrage! Superlatives! 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.

jamespo 10y ago

Token invalidation being an issue depends on the app. Checking against a blacklist / some secondary measure may only be required for important actions such as changing password, checking out, etc.

technion 10y ago

A lot of people are talking about the "none" algorithm issue, but the more recent vulnerability[0] is more telling: The report to the working group mailing list[1] led to the point that the standard had a "security considerations" section in the RFC, and this particular issue was never covered. 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-encryption https://auth0.com/blog/critical-vulnerability-in-json-web-en... [1] https://www.ietf.org/mail-archive/web/jose/current/msg05613.html https://www.ietf.org/mail-archive/web/jose/current/msg05613....

fareesh 10y ago

I use JWT in a couple of projects and it never once occurred to me to let the client decide the algorithm. I am not sure what use-case would necessitate something like that.

draw_down 10y ago
Guess that shouldn't be in the spec then.

akfish 10y ago

I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT. All I am getting is "JWT can be misused in such such way that makes your application vulnerable. And neither its standards nor libraries prevent that, so it sucks". But when is the last time we see any technology successfully prevented people from being silly?

ponytech 10y ago
I agree. I've read the whole article and still wonder why I should stop using JWT.
- slau 10y ago
  You shouldn't. Simply check that the hash algorithm specified by the client is the one you used when issuing the token. In a side project, I simply hard code the algorithm [1]. [1]: https://github.com/teotwaki/grace-calendar/blob/develop/app/helpers/jwt.rb https://github.com/teotwaki/grace-calendar/blob/develop/app/... Edit: DYAC.
RegEx 10y ago
https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228
nallerooth 10y ago
+1. I read the article and ended up with a TLDR where I expected some explanation and facts. It's a good thing that cookies have never been used in a bad manner. /sarcasm
sgift 10y ago
> But when is the last time we see any technology successfully prevented people from being silly? 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.)
10y ago

scandox 10y ago

I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). 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.

Klathmon 10y ago
If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not 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.
- 10y ago

regecks 10y ago

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 sign or verify a signature.

tptacek 10y ago
I agree. The OAEP thing was weird.
- yuhong 10y ago
  In fact, JWE and JWS are not as flawed as JWT is, right? ACME uses JWS.

Dowwie 10y ago

What I've gathered from this post is that the tech community ought to spend more time promoting JWT best practices because misuse can lead to bad times

andy_ppp 10y ago

Lock the encryption to RS512 and the standard is fine. I do a test against that and I also include a key relevant to and content I send with the token. This make the signature per request and considerably more difficult to forge. Maybe using JWTs for sessions is bad, using them for APIs is awesome with the specific caveats.

brutuscat 10y ago

Should we use Hawk + Oz[1]? [1] https://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-an-oauth-replacement/ https://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-...

robertlagrant 10y ago

Is using none a bit like using http instead of https? The standards support it, but it's 2017 so we shouldn't do it. 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.

hardwaresofton 10y ago

Can anyone think of some criticism for simply storing an API key and secret in localstorage for a web client? It's 50% bridging the gap between using cookies and a normal API and 50% simplifying frontends. The scheme I'm currently using on a project goes like this: 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.

mkohlmyr 10y ago
Perhaps I am missing something but I really don't see the point of storing it in localStorage or sessionStorage over cookies what so ever. 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.
- hardwaresofton 10y ago
  The reason I wanted to try this scheme was to finally remove the little difference in authentication method between web frontend and commandline/mobile API client... OWASP says not to do it (https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage_.28a.k.a._Offline_Storage.2C_Web_Storage.29 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.

StevePerkins 10y ago

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any 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.

tptacek 10y ago
I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, 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.

asanso 10y ago

The author of http://blog.intothesymmetry.com/2017/03/critical-vulnerability-in-json-web.html http://blog.intothesymmetry.com/2017/03/critical-vulnerabili... here FWIW. Personally I would not be so drastic. JOSE per se is not too bad (at least the idea is cool). Some crypto choices though have been really arguable...

tptacek 10y ago
That post is great work. Thanks again. But I think you're wrong about JWT. 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.

cashy 10y ago

feels like a troll piece

deleted 10y ago

[deleted]

ohstopitu 10y ago

so if JWTs are supposed to be avoided, what's a better alternative? cookies? (does that not open another can of worms?)

lucb1e 10y ago

This article jumps straight from introduction to conclusion. Like, "there have been big issues in the past and the available algorithms are questionable because [missing part] so don't use it". It hasn't quite convinced me.

Kiro 10y ago

OT but I need a wake-up call here. Upon login I'm sending back a generated UUID tied to the account and saves it as a cookie in the client. What's wrong with this approach?

russtrotter 10y ago
That approach is generally how many web platforms do their server-side session management. As with anything that is more or less home-grown (vs using that platform session implementation), you'll want to ask yourself: 1) how easy can my UUID be spoofed? 2) can i revoke/invalidate/logout my UUID session
davewritescode 10y ago
The only problem I can see is that depending on how you're generating the UUID you might be providing UUIDs that are guessable by a 3rd party.

pweissbrod 10y ago

Title misleading: JSON Web tokens should be avoided <FOR PASSING TO THE USER AS A SESSION KEY>

tfuqua 10y ago

When creating Universal JS apps, I usually store a user token as a cookie vs. local storage. I don't think you can server-side render content if you're using local storage.

davewritescode 10y ago

This article is slightly misleading. One should ALWAYS be suspect of any article that states X is always bad and should be avoided. Google, Facebook, Microsoft and hundreds of other companies are using JWT in security critical software. If you've ever logged into an app with Google, you've used JWT. 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.

mamoulian 10y ago

I suspect there are developers out there who haven't kept their secret as secret as it ought to be. The leak of a JWT secret allows for easier and more severe attacks than the leak of many other secrets.

tlrobinson 10y ago

For my current use-case, one of the appealing things about JWT is there are libraries for just about every language, which makes it easy for 3rd party developers to integrate with my service. Are there any better alternatives to JWT that have implementations in many languages? If not, elsewhere in this thread tptacek and others have suggested essentially `base64_encode(crypto_auth(json_encode(object)))` would be sufficient... is there any reason not to just slap a name on that "standard" and publish a bunch of libraries?

ash 10y ago
I was confused about libsodium/NaCl APIs, specifically crypto_sign vs crypto_auth. The difference: 1. `crypto_auth` is for secret-key signatures (auth): https://download.libsodium.org/doc/secret-key_cryptography/secret-key_authentication.html 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/public-key_signatures.html 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 https://news.ycombinator.com/item?id=13866983
- unscaled 10y ago
  Symmetric signature is simpler, leaner (in message size overhead), faster and more secure (by virtue of it being simpler). 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).
deathanatos 10y ago
> is there any reason not to just slap a name on that "standard" and publish a bunch of libraries? It was called JWT. jwt.decode(token, 'secret', algorithms=['HS256']) That's the Python for JWT; encode is similar. You can try something like what you suggest, but the devil is in "object": want your token to expire after a finite amount of time? You'll need to encode that yourself. Token need to be valid only for certain cases? You'll need to encode that yourself. Essentially, you end up reinventing the part of JWT that is relevant to your use-case, and hopefully, arrive at a decent API. At least in Python, python-jose's APIs will check not only the signature, but these additional claims (expiration of the token, that the token is applicable to the use we're verifying it for). (I still think we should be moving towards a common API (and JWT is good enough) and building libraries around that standard. They're going to fall short in some ways at first, and I wish people would help improve them. The suggestion of using base64/libsodium feel dangerously close to "rolling your own", because its too low-level for the purpose at hand.)

jchw 10y ago

Their suggestion to use secret_box is dangerous. It neglects to mention you still need to MAC the content, lest you leave open malleability attacks.

ChicagoDave 10y ago

Except for the fact that JWT's are fairly ubiquitous at this point. Depending on the needs of an API, the timeout is the big point. Banking apps generally timeout pretty quickly...as in 30-60 seconds. Mobile apps vary in how long a token stays valid, but many keep it short. 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.

zeveb 10y ago

I think that JSON Web Tokens (like most things involving JSON) are ill-thought-out, and they can definitely be a bit of a foot-gun, but they are also useful. 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.

throwawaysed 10y ago

This article has little substance. The arguments don't apply to JWT, it just mentions badly done implementations and an insecure option that obviously nobody would turn on. 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.

alejogutierrez 10y ago

This is my opinion about the article: 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.

kgilpin 10y ago

If you are interested in a Ruby library for signing and verifying a token containing a simple payload, take a look at our Slosilo library: https://github.com/conjurinc/slosilo#signing 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.

tracker1 10y ago

Personally, I've hand-written a few JWT implementations, and usually avoid even using a few of the "standards" often avoiding even reading the header. This is because usually I've used them for internal systems calling other systems. If you avoid reading the header, and have standard policy on signatures, combined with very short lived tokens (max 1m) combined with https, there is minimal risk. Yes, the standard is flawed, that doesn't mean the structure is inherently bad, or that using said design is bad by itself.

cdelsolar 10y ago

No they shouldn't, and stop spreading FUD. First of all, the headline has a blanket statement that they should be avoided, whereas the article says don't use them for sessions (which I agree with). There are many other uses for JWT that aren't sessions. The vulnerabilities the article brings up were quickly patched in all major libraries quite a while ago.

hdhzy 10y ago

Can anyone comment if TLS Token Binding [0] does solve some subset of problems usually solved with JWT? It seems to be scheduled for implementation in several clients [1]. [0]: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13 https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13 [1]: https://www.chromestatus.com/feature/5097603234529280 https://www.chromestatus.com/feature/5097603234529280