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

1–10 of 115 posts

Re: JWT Tokens are NOT safe

#2

Post by 0x5FC3 »

> JSON Web Tokens (JWT) are Dangerous for User Sessions—Here’s a Solution

Actual title on the website.

Edit: To watch clickbait work in real time, check OP's submit history.

Re: JWT Tokens are NOT safe

#3

Post by colesantiago »

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.

Re: JWT Tokens are NOT safe

#4

Post by RHSeeger »

> Security should be binary. Either technology is secure or it’s not.

From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.

Re: JWT Tokens are NOT safe

#6

Post by mbesto »

RHSeeger wrote: post #4

> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.

Ya, I hate to be pedantic too, but security it almost entirely NOT binary. It should be, but it's not.

Re: JWT Tokens are NOT safe

#8

Post by ralusek »

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

Re: JWT Tokens are NOT safe

#9

Post by ibraheemdev »

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 safe from attackers, but this method, along with pretty much any method that isn't storing some sort of state on the server, has the same 3 problems listed in the article.

   1. Logout doesn’t really log you out!
   2. Blocking users doesn’t immediately block them.
   3. Could have stale data
I know there are ways around this with a really fast refresh time, or as I've heard, storing some sort of signature in the cookie, but I personally prefer a plain old server-side session store with something like Redis, or even just an in-memory HashMap. Authentication doesn't have to be that complicated.
Post reply on HN