JavaScript Object Signing and Encryption is a bad standard (2017)
paragonie.com
paragonie.com
We're developing a simply secure alternative, called
PASETO (Platform-Agnostic Security Tokens).
Hey wait a minute, this secret message is just an advertisement!
[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.
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.
I think it's uncontroversial to say that RSA in practice is a fraught proposition. There are a lot of foot-guns that even the mainstream libraries don't protect you from, so just using RSA means you need to spend a lot of time making sure you're not using it the wrong way, and "how to use it right" isn't elegantly contained in a Stack Overflow answer anywhere. And because RSA comes with so many knobs to turn, it ends up being an extensive analysis task for the poor developer whose job is to write the code. I've been that developer.
However, if the choice is between (1) using RSA, with caveats, because the tech stack is already mostly RSA, and (2) updating the whole tech stack to ECC based algorithms, we are not yet at the point where option #2 is always the right answer.
The (biggest IMO) problem with RSA is that unlike ECDSA or ECDH or EdDSA it's usable for BOTH signing AND encryption, and re-using the same keys for both signing and encryption can be catastrophic (if you screw up the padding, which is another uniquely-RSA footgun). It's far, far easier to have a signing algorithm with signing keys, and an encryption algorithm with encryption keys than it is to have a single algorithm that does everything but requires the user to get all the options right. By working the same "both ways" RSA makes asymmetric key management even harder, and it's already one of the hardest parts of cryptography!
A shakier reason is speculation that prime factorization could be more solvable problem than elliptic curves.
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.
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.
Until then, this is pretty much noise.
OIDC seems to be the de-facto standard today.
im curious about this. normally 'logging out' just involves deleting the secure http-only cookie where the jwt was stored. is there something I'm missing here?
Enforcing this implies to implement access control on each (critical) request, giving little advantage to a self contained token compared to a pure stateful signed session token.
With JWT you need to store forcibly terminated active sessions in server. Those sessions are short-lived. So basically it's empty map.
Another solution with token is to change server key and force all short lived sessions to reauthenticate. It is not very nice, but if that's an extremely rare scenario, it might be appropriate to get rid of checking each request while still supporting forcible logout.
You can kind of fake this by using a short-lived JWT and constantly refreshing it, but this:
1. Massively increases server strain and bandwidth usage
2. Has problems with users less reliable connections (they'll be randomly logged out all the time)
3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)
Here's a good graph on why $method to make JWTs work for sessions is bad: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... (note: for some reason the website doesn't support HTTPS :( )
A short-lived JWT that fits into an HTTP Header is not going to _massively_ increase your bandwidth usage. At most, you will end up with a single refresh request every few minutes as each short-lived JWT expires.
> 2. Has problems with users less reliable connections (they'll be randomly logged out all the time)
Usually if your request failed due to a bad connection, the client wouldn't be designed to automatically log out the user. That would be just terrible UX.
> 3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)
Incorrect. A short-lived JWT tied to a refresh token allows for a remember-me style feature by checking account access when issuing a new JWT token.
The skiny is that you place a copy of some monotonic counter inside every JWT you issue, you keep track of the counter server side and compare with each request's JWT copy + some delta (which is the equivalent of maximum number of concurrent sessions you wish the user to have).
if you _had_ to do that, I would put the counter into something like redis instead.
10 timeout to reply. o_O
1. I don't believe there are any real security issues regarding logout if JWTs have a sufficiently short expiration time.
2. The reason this issue comes up is because of compliance audits, who demand that as soon as the user logs out, that the supplied token becomes invalid. However, if the JWT is adequately discarded from the client, the fact that the JWT is still valid for another ~5-10 minutes or so is only a security risk if the token has already been stolen. The fact of the matter here is you really aren't protecting against a new attack vector with this "must immediately revoke tokens on logout" rule.
3. Despite my beliefs with #2 (and I'd love to hear an argument why this isn't valid), good luck trying to convince an auditor about that fact, who often love finding minor/mundane issues to justify their existence. So you'll still need to maintain a small blocklist, but the data in that list is usually very small (most users never log out these days) and can often be replicated in memory to each server.
The sum of both lists is vastly smaller and easier to manage than distributing session state and maintaining it server side for every single user.
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?
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.
I am not stating any opinion upon JWT or alternatives.
If JWTs don't match up with your use case, don't use it! Opaque, server bound tokens are fine in many cases.
One of the main issues I have with JWT is that it has a fairly high degree of cryptographic agility rather than a version number that specifies a set of cryptographic primitives.
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.
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.
Also, with regarding to REST "front-end servers" aren't part of the discussion, but an implementation detail.
My interpretation is aligned with this: https://www.ibm.com/docs/en/sdi/7.2.0.2?topic=reference-rest...
"...but creates no load and consumes no per-client storage on the set of servers or on the network"
So no, per-client session state would be against the principles of REST in my view.
https://stackoverflow.com/questions/3105296/if-rest-applicat...
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.
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.
I think the encryption isn't necessary but hey why not.
Frankly, JWTs are very low on the “what’s broken” priority list.
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.
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.
* 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.)
I can use a screwdriver as a makeshift hammer, but should I?
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.
Javascript Object Signing and Encryption is a Bad Standard (2017) - https://news.ycombinator.com/item?id=22364638 - Feb 2020 (55 comments)
JSON Web Tokens should be avoided - https://news.ycombinator.com/item?id=13865459 - March 2017 (297 comments)
And to be more objective while writing public blog posts.
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/)
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.
Edit: The previous version of the title mentioned JWT.