Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ten years of JSON Web Token and preparing for the future

self-issued.info

Post reply on HN
Print view View original

81–90 of 159 posts

Re: Ten years of JSON Web Token and preparing for the future

#81

Post by unscaled »

cyberax wrote: post #31
francislavoie wrote: post #23

Paseto is better https://paseto.io/ , but unfortunately OAuth forces the usage of JWT.

I fail to see how it's better, except for hand-waving about potential crypto attacks? It seems to be a NIH-ed serialization format with hard-coded ciphersuits. It doesn't seem to support use-cases like delegation and claims.

these "potential crypto attacks" resulted in multiple CVEs and several real life attacks. I think even the Storm-0558[1] could be traced to how hard it is verify a valid JWT, due to some of the over-engineering mistakes that have been involved in the standard's design. I don't know if PASETO would have solved that particular attacks, but the PASETO standard solves some of the most common CVEs we see with JWT libraries: alg=none, Algorithm Confusion attacks and invalid curves.

[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...

Re: Ten years of JSON Web Token and preparing for the future

#82

Post by [deleted] »

KPGv2 wrote: post #48
martinald wrote: post #41

The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…

[flagged]

[deleted]

Re: Ten years of JSON Web Token and preparing for the future

#83

Post by deeringc »

fifticon wrote: post #66
martinald wrote: post #41

The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…

I have a random idea regarding compromised tokens, which may not hold water. What if you put things like the client's IP address in the token? Then the server can reject (and mark for compromise) as soon as they receive any request from a different ip address? I realise this will also invalidate people who somehow roam between ip addressses, say DHCP/wireless in a larger building.

Enterprise customers often have split tunnel VPNs or proxies (with PAC configs) where part of the traffic may go through a VPN and another part goes directly. So for example a customer admin might configure an app that does email and webRTC so that the real time traffic (media and the associated signalling) goes directly and the email traffic goes via some TLS intercepting proxy for some compliance reason or DLP. This can result in one application having multiple public IPs for different network requests, even while they are on one internal network (not even jumping between networks like you say). That isnt something that the application author can control, it's the customer admin that decides to do that.

Re: Ten years of JSON Web Token and preparing for the future

#84

Post by afiori »

KPGv2 wrote: post #48
martinald wrote: post #41

The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…

[flagged]

But then how are JWT different from opaque session tokens? Both still need server side checks for anything

The truth is that JWTs have always been meant for authorization, they just were applicable to very few cases almost exclusively at Google scale

Re: Ten years of JSON Web Token and preparing for the future

#85

Post by afiori »

KPGv2 wrote: post #48
martinald wrote: post #41

The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…

[flagged]

> That's what makes JWT-based calls stateless:

> I decrypt it to get the userId, then do the role lookup

A if every auth needs a database lookup then it is not stateless. A JWT is stateless if and only if you trust its signature "offline"

Re: Ten years of JSON Web Token and preparing for the future

#86

Post by orphea »

littlecranky67 wrote: post #67
fmbb wrote: post #62

Earlier quoted context omitted.

What you describe sounds like it will make any explicit log out action users do on any device turn into a ”log me out from all devices” action, which was probably not at all the user’s intent unless that is the only explicit option you give them.

A "logout" action from the user should just delete the JWT from the device he is using. Asuming the token wasn't compromised, there is no backend work involved. Is this as secure as doing a blacklist for non-expired tokens? No, it isn't. It is a sane tradeoff between decent security and implementation complexity.

  > A "logout" action from the user should just delete the JWT from the device he is using.
I wouldn't say should. It may. If you're fine with inability to terminate sessions on other devices.

Re: Ten years of JSON Web Token and preparing for the future

#87

Post by afiori »

harrall wrote: post #29
hdjrudni wrote: post #17

Every time I want to use a JWT, it seems like it's the suboptimal choice, so I've never found a genuine use case for them. Most recently, I wanted to implement 2FA w/ TOTP. I figure I'll use 1 cookie for the session, and another cookie as a TOTP bypass. If the user doesn't have a 2FA bypass cookie, then they have to complete the 2FA challenge. Great, so user submits username & password like normal, if they pass but d…

Long before JWT existed, if you wanted to pass some trusted data through an untrusted channel, you would make a payload with an expiry, encrypt or sign it with your secret key, then send it. However, you would need to make up your own way to send this info. For example, if this were a website, you might dump the signed/encrypted payload into several form fields and upon receiving it back, you would verify that it was…

The issue with JWTs is that it is very often misused standard

Re: Ten years of JSON Web Token and preparing for the future

#88

Post by rollcat »

akoboldfrying wrote: post #75
hn_throwaway_99 wrote: post #45

Earlier quoted context omitted.

> For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got whatever else was in the claim there quickly. FWIW, I built a system previously that got around this "having to check the DB on every access to check for revocations" issue that wo…

This seems like about the best that can be done (well, you could go full Bloom filter to squeeze that revocation list size down even further), but it does seem vulnerable to DoS: Create 10000 accounts and log them all out at the same time to force the server into the slow PostgreSQL mode.

Any system that allows you to create 10000 accounts is already vulnerable to DoS.

Also, as vintermann suggested, you can use a faster, domain-specific database if you're concerned about this becoming an issue. And sometimes edge cases like this aren't worth considering until you hit them.

Re: Ten years of JSON Web Token and preparing for the future

#89

Post by rollcat »

hn_throwaway_99 wrote: post #45
martinald wrote: post #41

The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…

> For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got whatever else was in the claim there quickly. FWIW, I built a system previously that got around this "having to check the DB on every access to check for revocations" issue that wo…

Overall this sounds good, but:

> 1. Almost no statefulness, which was great for scalability.

This is called "eventual consistency", it's probably fine in practice but you still do have a lot of state. Personally, if I have any in-application state at all, I would use a sticky cookie on the LB to send each client to the same instance.

Re: Ten years of JSON Web Token and preparing for the future

#90

Post by littlecranky67 »

orphea wrote: post #86
littlecranky67 wrote: post #67

Earlier quoted context omitted.

A "logout" action from the user should just delete the JWT from the device he is using. Asuming the token wasn't compromised, there is no backend work involved. Is this as secure as doing a blacklist for non-expired tokens? No, it isn't. It is a sane tradeoff between decent security and implementation complexity.

> A "logout" action from the user should just delete the JWT from the device he is using. I wouldn't say should . It may . If you're fine with inability to terminate sessions on other devices.

Terminating sessions on other devices is not possible, but another tradeoff is using a "Logout from all devices" mechanism. In that case you just have a global "token not issue before" field, and when you logout from all devices, set that timestamp to the current time (and all issued tokens will fail authentication). But again, tradeoff. You individual requirements may vary.
Post reply on HN