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

JWT Tokens are NOT safe

redislabs.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: JWT Tokens are NOT safe

#91

Post by benlivengood »

If an application needs a total order over authentication,authorization, and transactional events then redis doesn't cut it either. Take this scenario:

1. User A creates resource X

2. User A sets X=1

3. User B fails to set X=5

4. User A transfers ownership of X to B

5. User A fails to set X=4

4. User B sets X=2

This scenario happens in all sorts of applications; games, document editors, financial ledgers, forums, etc. Ownership transfer is the hardest use case to support with time-limited tokens like JWT, but even cached sessions or external security services may not be sufficient because proper ordering requires ACID compliance between security and data storage. Failing to provide a total order over auth* and modification events leads to race conditions and bugs.

Ownership transfer is mostly a superset of resource deletion (how long the actual resources persist in storage varies) so if an application accepts an authorization/authentication token as evidence that a resource (including a user account) still exists it can lead to reference-after-free or stale reference bugs, especially in systems where resource identifiers can be reused, or inconsistencies and race conditions in logic that makes decisions based on assumption of event ordering, e.g. orphaning related objects that would normally be deleted when the parent/child is deleted but which fails if the owning user no longer exists, despite the authentication layer allowing the initial deletion to occur due to stale credentials.

If correctness is the goal then authorization decisions need to be made in the same transaction as the action being authorized, and authentication changes need to at least occur no later than corresponding authorization changes, e.g. revoking access before deleting a user or transferring ownership or invalidating sessions/cookies/JWTs that can't be updated in the same transaction.

Re: JWT Tokens are NOT safe

#92

Post by ibraheemdev »

mbell wrote: post #64
ibraheemdev wrote: post #9

This doesn't only apply to the way JWT tokens are usually used for sessions (no persistence). The default session store for Devise (Rails) and .NET Identity is cookies, on the client. They are encrypted with a secret key and decrypted for authentication. Identity in particular allows you to store any number of "claims" in the cookie, such as a username or role. Because the cookies are signed and HTTP only, this is sa…

Regarding Devise + Rails cookie session store: 1. Logging out deletes the cookie, you are really logged out. If your session cookie got stolen, you have other issues but I don't think this is really a matter of being 'logged out'. It is pretty easy to implement 'revoke all sessions for this user' type of logic with Devise and Devise does this of the box when a user changes their password. 2. Permissions are orthagona…

For 2 and 3 I was mainly referring to Identity, although I'm not sure how it works internally. For 1, I think the main issue is that when someone logs out, or you log someone out, you aren't guaranteed that they are actually logged out. There are cases where this does matter.

How does Devise handle 'revoke all sessions for this user'?

Re: JWT Tokens are NOT safe

#93

Post by jopython »

ppcelery wrote: post #58

maybe you can add a `sid` in jwt token, then store this sid in redis. when you want invoke a session, just del this sid in redis.

The author mentions that "One popular solution is to store a list of “revoked tokens” in a database and check it for every call. And if the token is part of that revoked list, then block the user from taking the next action. But then now you are making that extra call to the DB to check if the token is revoked and so deceives the purpose of JWT altogether."

I believe the author is 'assuming' the devs are not using a db to validate revoked sessions.

Re: JWT Tokens are NOT safe

#94

Post by jopython »

ralusek wrote: post #8

TL;DR as always, is that there's nothing wrong with JWT. The problem is with thinking that there is a way to have an authentication token that isn't persisted in any way, so long as you want the ability to invalidate a token (i.e. logout, user banned, password change, etc).

Rightly said.

Re: JWT Tokens are NOT safe

#95

Post by spect88 »

ibraheemdev wrote: post #92
mbell wrote: post #64

Earlier quoted context omitted.

Regarding Devise + Rails cookie session store: 1. Logging out deletes the cookie, you are really logged out. If your session cookie got stolen, you have other issues but I don't think this is really a matter of being 'logged out'. It is pretty easy to implement 'revoke all sessions for this user' type of logic with Devise and Devise does this of the box when a user changes their password. 2. Permissions are orthagona…

For 2 and 3 I was mainly referring to Identity, although I'm not sure how it works internally. For 1, I think the main issue is that when someone logs out, or you log someone out, you aren't guaranteed that they are actually logged out. There are cases where this does matter. How does Devise handle 'revoke all sessions for this user'?

> How does Devise handle 'revoke all sessions for this user'?

The cookie has both user id and a special token which IIRC is a substring of the user's password salt. Retrieving current user from cookie includes not only looking up by id, but also verifying the salt. So if you change the password, the salt is also changed and all the old sessions will stop working.

Re: JWT Tokens are NOT safe

#96

Post by ibraheemdev »

spect88 wrote: post #95
ibraheemdev wrote: post #92

Earlier quoted context omitted.

For 2 and 3 I was mainly referring to Identity, although I'm not sure how it works internally. For 1, I think the main issue is that when someone logs out, or you log someone out, you aren't guaranteed that they are actually logged out. There are cases where this does matter. How does Devise handle 'revoke all sessions for this user'?

> How does Devise handle 'revoke all sessions for this user'? The cookie has both user id and a special token which IIRC is a substring of the user's password salt. Retrieving current user from cookie includes not only looking up by id, but also verifying the salt. So if you change the password, the salt is also changed and all the old sessions will stop working.

Ah okay, so Devise does lookup the user in the database to authenticate. I guess it's not applicable to my premise then.

Re: JWT Tokens are NOT safe

#97

Post by node-bayarea »

ibraheemdev wrote: post #9

This doesn't only apply to the way JWT tokens are usually used for sessions (no persistence). The default session store for Devise (Rails) and .NET Identity is cookies, on the client. They are encrypted with a secret key and decrypted for authentication. Identity in particular allows you to store any number of "claims" in the cookie, such as a username or role. Because the cookies are signed and HTTP only, this is sa…

This is exactly the point of the blog. If you are using JWT + Workarounds to make it secure, then you'll loose all the benefits. This is why virtually no one in fin-tech use JWT.

Re: JWT Tokens are NOT safe

#98

Post by node-bayarea »

jmcgough wrote: post #19
colesantiago wrote: post #3

OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.

There's "JWT hate" articles on HN because people keep implementing JWT auth without understanding it - they want an easy, cheap way to do auth when talking to different services, but it can be a huge security flaw since you can't do revocation. There's a lot of ways to configure JWT, so it's very easy to shoot yourself in the foot. JWT for short-lived tokens is fine - it can work well for signing requests between mic…

+1

Re: JWT Tokens are NOT safe

#100

Post by node-bayarea »

CameronNemo wrote: post #79

I flagged this post for the following reason: Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity. The user's submission history is almost completely RedisLabs content.

I post all sorts of stuff if you look into the complete history. The blog legitimately identifies and highlights the issues that a ton of security experts have already identified for years and written about. May I ask you to un-flag it?
Post reply on HN