1

I'm building a nodejs server with jwt authentication.

At the moment my jwts have a expiration time of 1 month. If the user goes on the loggin page, I check if his request contains a valid jwt, if yes, he don't have to type in his username and password. If he logs out, the jwt gets deleted on the clientside, so the user have to log in next time with his credentials.

What if an attacker listens to the connection (I'm already using ssl) and gets the token. Even if the user logs out and gets a new token on his next session, the attacker can impersonate the user with the old token, as long as it is valid right?

  1. Is it a good idea to store the IAT of the "current" token of the user in the DB and compare it to the IAT of the token in the request to avoid the access of the attacker?

  2. I know, 1 month is quite a long time for a jwt. I also had the idea to generate a new token, every time the client logs in (with exp. time 2 days). But if an attacker gets only 1 valid token, he also gets the new tokens, isn't he?

Do you have any suggestions?

Thanks, Cheers!

mcAngular2
  • 299
  • 1
  • 14

2 Answers2

2

Your concerns are exactly one of the reasons that security people advise against using JWTs for session data -- see section "You cannot invalidate individual JWT tokens". In other words, the only way to invalidate JWT tokens is to force a database lookup when it is presented -- but that defeats the entire point of the JWT in the first place (most people use them because they are trying to avoid a database lookup on the server).

TheGreatContini
  • 6,429
  • 2
  • 27
  • 37
  • what should I then use instead of JWT ?;) – mcAngular2 Oct 25 '18 at 19:33
  • 1
    @mcAngular2 The traditional way of doing session management is with a session id that is stored in the database. Just about every web application framework provides support for this. Many developers are switching to JWTs to avoid the database access, but as we see for exactly the point you raised, it comes at a security consequence. If you are using Oauth or open id connect, using JWTs is reasonable provided that you have short life times for access tokens -- but you wouldn't want to do it for refresh tokens. – TheGreatContini Oct 25 '18 at 20:57
  • I agree with this answer. JWT shall not be used for session management. For the record, please note that recent specifications also allow to bind a token to the current connection (HTTPS or HTTP) RFC8471 to RFC8473 preventing stolen tokens to be used. – Spomky-Labs Oct 26 '18 at 23:01
-1

Store the tokens and any session data (for example user ID for the logged in user) on the server. This gives you full control of the data, and the sessions. It also removes a lot of avenues for abuse (which the JWT standard allows).

When doing that, if you know a token is stolen, you can simply mark it as invalid on your server, and have your application ignore it.

In practice, this means just having a token in the cookie, and having the user ID and other session data stored in a database table or server side cache (for example a mysql table or redis cache).

HumaneWolf
  • 89
  • 1
  • 2