0

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?

3
  • Why would you make your sessions this long? – MechMK1 Feb 12 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. – Shoe Diamente Feb 12 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 at 18:23
0

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.

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.