8 ms·
JavaScript Object Signing and Encryption is a bad standard (2017)
- al2o3cr 5y agoWe're developing a simply secure alternative, called PASETO (Platform-Agnostic Security Tokens). D. R. I. N. K. Y. O. U. R. O. V. A. L.... Hey wait a minute, this secret message is just an advertisement!
- warent 5y agoFor anybody wondering, this is a reference from the cult classic movie A Christmas Story. Very funny, brings back memories
- singlow 5y agoOr it's a reference to a real life marketing campaign that was referenced in that movie? [Edit] So I googled. Never realized that message was never a real secret code from the radio show. Sponsored by Ovaltine but apparently the creators deny having put ads in the secret messages as the movie claimed.
- Taylor_OD 5y agoOnce a week an article like this gets posted.
- silasdavis 5y agoYeah it's curious isn't it? Seems to get more attention than I understand.
- firemelt 5y agoanyone have secure battle tested tutorials how to done api auth without jwt?
- chrisabrams 5y agoI'd be wary of any tutorial that claims to be battle tested.
- robertlagrant 5y agoPrint it out and use it in a rolled up paper fight?
- tomwojcik 5y agoI'm not sure what exactly do you want to learn but the most popular auth method for django rest framework is a token based auth, which differs from jwt. So maybe start there. And DRF as a lib is battle tested.
- numbsafari 5y agoConvince AWS, Azure, Google to abandon JWT for their APIs and we’ll talk. Until then, this is pretty much noise.
- ori_b 5y agoAnd how, precisely, do you propose doing this convincing without popularizing the idea that it's a bad API?
- SamBam 5y agoUse the flaws to exploit an AWS, Azure or Google product? And if you can't, are they really flaws? Or is this just an issue of some people implementing the standard badly, and they need to be taught to use better libraries?
- Godel_unicode 5y agoI might slightly amend that to the less illegal "use the flaws to submit bugs to their bounty programs and get paid for your time".
- ori_b 5y agoYou mean, like this? https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple/ https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-a... It's certainly possible to use JWT correctly, and with sufficient resources put towards auditing, most flaws will be caught. This doesn't make it a good design.
- GoblinSlayer 5y agoIt's linked in the article: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
- 0xEFF 5y agoAnd also GitHub, Gitlab, Auth0, OKTA, login.gov, Atlasssian, Kubernetes, Hashicorp, etc… OIDC seems to be the de-facto standard today.
- KingMachiavelli 5y agoOh thank God. I was worried I was going to have to stop using the Java web toolkit.
- schnable 5y agoOld article (2017) that misses the point of JWT entirely.
- ferdowsi 5y agoJWTs are perfectly fine as a set of signed attributes if you are not using them for stateless session management (what big apps actually do this, in practice?). Most (if not all) popular JWT libraries reject "alg: none" at this point. If JWTs don't match up with your use case, don't use it! Opaque, server bound tokens are fine in many cases.
- flowerlad 5y ago> if you are not using them for stateless session management REST APIs are required to be stateless, meaning the server does not store any state about the client session on the server-side. When you have multiple servers servicing requests there is no guarantee that subsequent requests will go to the same server. So having session state in memory won't work. There is nothing wrong in using JWT tokens with a REST service. In fact most services do just that.
- kijin 5y ago> When you have multiple servers servicing requests there is no guarantee that subsequent requests will go to the same server. Distributed key-value stores have been a thing for ages. Besides, the information you are accessing and manipulating through that REST API is probably stored in some sort of database, so you most likely already have a straightforward way to share state among your frontend servers. It's only a matter of whether it's fast enough for your purpose. Most people don't even have to go "distributed" on the backend. A single Redis instance can handle upwards of 1 billion requests per day.
- dvfjsdhgfv 5y agoThe Java Web Toolkit is a neat idea, but the licensing terms are a bit cumbersome. Edit: The previous version of the title mentioned JWT.
- macspoofing 5y ago>We're developing a simply secure alternative, called PASETO (Platform-Agnostic Security Tokens). Of course. Because a new unproven, untested security standard will fix things ... and certainly doesn't introduce it's own set of issues and vulnerabilities (https://xkcd.com/927/ https://xkcd.com/927/) The reality is that much of the problems with JWT came from misconfigured (or not configured) libraries. That's an issue for sure. On the other hand JWT is used by EVERYONE so they are a known-factor and there's value in the fact that this standard has been battle-tested across many companies, and use-cases.
- danpalmer 5y agoThe arguments against JWTs always seem to boil down to them having too many sharp edges that are too easy to get wrong. That is a good argument against things in isolation, but we're not working in isolation, we have classic old server-side sessions with cookies and session IDs and so on. Are JWTs better than those? Well... kinda? Sessions are _hard_ to get right. Frameworks can do 80% of the work, but not everyone uses frameworks that handle them, and the last 20% is still hard. Then working in a multi-service environment that all gets much harder. Could JWTs be improved? Maybe. Does that mean we should avoid them? Probably not, they solve a certain kind of problem better than the available alternatives, and rolling your own alternative is only one step away from rolling your own crypto.
- mmazing 5y agoEverything is a tool in a toolbox. JWTs are not a good replacement for sessions for a couple reasons - * You can't have decentralized authentication AND invalidate a token. * You have to have complicated client side logic (opposed to a cookie with a session id) to maintain your tokens. (Much of this is "solved" by using third party packages to handle it.) To me, it's reinventing the wheel to use JWTs as long term mutable storage. JWTs are GREAT for short term authentication between decentralized systems. I can use a screwdriver as a makeshift hammer, but should I?
- DrBenCarson 5y agoPosted 4 years ago, and yet OIDC is still the closest thing we have to an auth standard. Frankly, JWTs are very low on the “what’s broken” priority list.
- deleted 5y ago[deleted]
- mmazing 5y agoI've worked on projects that used JWT to maintain session data and it's definitely a horrible idea. Halfway through the project it became very apparent that we were reinventing the wheel - having to solve problems that were never an issue with maintaining session data server side. However, I currently use JWT for short term authorization tokens (5 minute expiration) between a web api and a websocket service. The service needs to be lightweight and not rely on database hits to confirm authorization. But yeah, JWT gets misused VERY often.
- SV_BubbleTime 5y agoAs I understand it, it’s when people put the kitchen sink I to claims. Is that a fair single sentence description? Aside, the idea you can set the entire JWT to “no security” from a signed packet and have a chance at a server accepting it, is crazy.
- mmazing 5y agoIn our case we only pass a user id (which is public information anyway) and encrypt the token on top of that. I think the encryption isn't necessary but hey why not.
- IggleSniggle 5y agoI just want to point out that the article mentions the session issue upfront only to get it out of the way, and follows the session issue with its own set of interesting complaints.
- Nursie 5y agoJWT is widely deployed in a huge number of places and is a bit of a favourite in the banking industry at the moment. It's going to take a lot to displace it. It's also not solely used for session management (I've never used it for that). Paseto looks fine, it avoids some of the pitfalls of weak algorithms etc, but that's not exactly tough to mitigate. They even say in the page that keeping a whitelist of algorithms is the approach most people take to JWT anyway. Could JWT be made stronger and more foolproof? No doubt, but I'm not sure that at this point the world is ready to move on, in fact we seem to be going gangbusters deploying and developing around it. If PASETO is the future, perhaps the PASETO guys could talk to the OpenID folks and see if they can get some traction. But this is going to need to be led by the standards bodies and not by individual developers.
- upofadown 5y ago>Most cryptographers recommend migrating away from RSA. They do? This strikes me as an exceptional statement that smacks of crypto fandom especially when combined with a later complaint that their favourite curve is not supported.
- holtalanm 5y agoi have never seen anything anywhere advocating for moving away from RSA. i'm curious to see what their sources are for this claim.
- vbezhenar 5y agohttps://news.ycombinator.com/item?id=25022845 https://news.ycombinator.com/item?id=25022845 (https://blog.trailofbits.com/2019/07/08/fuck-rsa/ https://blog.trailofbits.com/2019/07/08/fuck-rsa/) for example
- holtalanm 5y agowatched the whole thing. was very informative. Actually havent used RSA in any capacity in years (AES is a lot easier to use), but always viewed RSA as a battle-tested encryption method/alg. I suppose with anything there are ways to misuse it, and RSA appears to be really easy to misuse.
- noodlesUK 5y agoI would say that it’s fairly rare that RSA and AES are really competitors for the same category of uses, as they’re asymmetric and symmetric algorithms respectively. I would suggest that anyone who doesn’t know about the differences between these things just not use cryptography directly and instead use things like libsodium which has sane defaults and a hard to misuse api. If you don’t know cryptography fairly well, it’s a massive minefield.
- jnwatson 5y agoIn 2005, The NSA began recommended migrating away from RSA and onto ECC algorithms for its customers' classified use cases. [1] In 2018, it paused that recommendation, essentially arguing that if you haven't migrated already, wait until the quantum-resistant algorithms are well vetted to avoid a second migration. 1. [https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography]
- jeswin 5y agoI think the real take away here is to choose the right tool for the job; and that even JWT is many times a good fit when used correctly. And to be more objective while writing public blog posts.
- davewritescode 5y agoPlease get back to me when you have a an implementation on the JVM that doesn't require libpaseto. The reason JWT is used everywhere is because it's usable on almost every stack you could possibly imagine. We all agree that JWT had some egregiously bad design decisions in the past that have all been papered over in most libraries. Compared to XMLDSig, JWT is much better and XMLDSig has been widely deployed and used for almost 2 decades at this point, including some very high security applications.
- dingosity 5y agoor you could validate parameters from unauthenticated actors (like algorithm) and return an error if it does not match your expectations. you're allowed to reject a parameter if you don't support that parameter; looking at it and deciding that "alg: none" isn't acceptable counts as "understanding" a required header.
- ChrisArchitect 5y agoDiscussion from only a year ago: https://news.ycombinator.com/item?id=22364638 https://news.ycombinator.com/item?id=22364638
- dang 5y agoA couple of past discussions: Javascript Object Signing and Encryption is a Bad Standard (2017) - https://news.ycombinator.com/item?id=22364638 https://news.ycombinator.com/item?id=22364638 - Feb 2020 (55 comments) JSON Web Tokens should be avoided - https://news.ycombinator.com/item?id=13865459 https://news.ycombinator.com/item?id=13865459 - March 2017 (297 comments)