I'm not sure what's the option to store and manage session IDs for long lived sessions (3-6 months each).

Given that the session ID is generated with enough entropy and that the session ID is then given to the user via SSL and a Secure, HttpOnly cookie, these are the options I came up with for storing the session ID:

  1. Just store the session ID in plain text in the database or file system
    • Pros: fast, easy
    • Cons: any compromised backup or unauthorised access to the database gives access to all active sessions
  2. Give both a session ID and a session key to the user and hash the session key before storing them into the database
    • Pros: secure both if the user compromises the server and the database
    • Cons: possibly slow (IIRC cryptographically safe hashing functions are intended to be slow) for something that needs to occur at every request
  3. Create a signed JWT token over that session ID with a secret stored on the server
    • Pros: probably faster than hashing, bigger tokens (as in length)
    • Cons: not secure if both the server and database are compromised

What the recommended way to manage and most importantly store sessions?

  • Why would you make your sessions this long?
    – MechMK1
    Feb 12, 2021 at 9:09
  • @MechMK1 User convenience. Being signed out every week or month is not exactly pleasant. I guess I could shorten it to 1-3 months, but the main problems still stand. Feb 12, 2021 at 9:14
  • Long-lasting sessions of this kind are typically an illusion. In reality, the site issues a persistent token (a cookie usually) that is either signed or encrypted and contains information about the user and possibly the device. When the browser presents the token, the site validates the token and creates a new session-- silently, to make it seem like the session had lasted the whole time. Literally keeping a session that long would cause a lot of problems.
    – John Wu
    Feb 12, 2021 at 18:23

1 Answer 1


I think your threat model about a compromised server is a little odd, though I certainly don't fault you for being concerned about leaving secrets and sessions exposed like that. The thing is, if your server and/or database are compromised, sessions will probably be the least of your concerns; the attacker can already view and manipulate all of your data (assuming it's not encrypted with the key stored out of reach). At this point, sessions/secrets may only be marginally useful to the attacker for maintaining access in case they lose their access to the compromised server/database. There's nothing wrong with trying to practice defense in depth and mitigate this threat, but there's definitely a point in which you have to trust something on the server, else you will never get anything done.

My recommendation is to find a framework or library that fits your needs, and most importantly, has already implemented session management securely. Even for someone already well versed in security, there are serious pitfalls that must be avoided when implementing something like this from scratch; it's often better to use a proven implementation.

As pointed out by @JohnWu in the comments, sessions of the length you mention are usually an illusion (although, nothing stops someone from doing it). Typically, sessions have an expiration date, but are continuously refreshed and extended as the user interacts with the service. There is a common paradigm of using both access and refresh tokens (often with JWT) where the access token is short lived, and must be periodically replaced by using the refresh token.

  • also key here is that the refresh token is one-time use. That helps secure things a bit more. The server would know if it were used twice and could notify the user via e-mail. Which is why you should never rely on a session alone to allow access to change the user's account info. (force them to login again to change...)
    – pcalkins
    Nov 10, 2021 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.