Remember me feature: do we need a server side token if the cookie is signed by the server?

Question

Every resource I find (I, II, III) about how to implement in a secure way the typical "remember me" login feature, recommends storing a user identifier and an associated unique token in the cookie, and then the hashed token associated to the user in the database. This way we are safe of:

• User impersonation. Should we store remember_me_user_id=93 in the cookie, it would be quite possibly to log in as admin crafting a cookie with remember_me_user_id=1. Adding the unique token to the cookie prevents from that.
• Timing attack. The user identifier is used to look up the user, so the time elapsed is indifferent because it is searching but not authenticating. Should we look up by the unique token, the time information could be used to craft a valid token character by character.
• Rainbow attack. The token is stored hashed in the database, so if the table information gets compromised it is useless.

But what about if we just store the user identifier in a cookie signed using a server secret? As far as I see, it prevents from the very same kind of attacks:

• User impersonation. The cookie is signed, so an attacker can't craft another valid one without the server side secret.
• Timing attack. The cookie is signed, so the attacker can't create it step by step.
• Rainbow attack. No token stored in the database, no worries.

And, as far as I see, it has the same dangers that the cookie with the token:

• You have to trust that the browser will expire the token when the time arrives. Solution: Timestamp the cookie and compare the time in the server.
• XSS attack. Solution: Mark the cookie as http_only.
• Eavesdropping. Solution: Mark the cookie as secure and use https.
• Having a long lived cookie which is able to authenticate a user is very dangerous. Mitigation: 1) Refresh the cookie and token at every X requests in a server token based solution (it will still last all the period if the user does not come back). 2) Refresh the cookie and extend its timestamp at every X requests in any of both solutions (then you are "remembering" for a shorter period if the user doesn't come back).

Is my rationing correct or am I missing something?

Answer 1

Congratulations! You've just invented the JWT :)

A "remember me" feature isn't practically different than a simple session token, and the entire point of JWTs is to not have store tokens server-side while still validating users.

No need to implement this yourself of course - every language has good libraries for JWTs. You should also read up on their limitations, the biggest of which is the inability to revoke them. That is why they have an expiration, which is usually quite short, and so are combined with a refresh token, which lives longer.

Helpful reference: https://jwt.io

Answer 2

If you're just storing the user name (and not the password), a client-side-only solution is fine. The user will still have to authenticate, so the risk is fairly small, and if the cookie is stolen it isn't very valuable.

If you're storing a token that also authenticates the user, you must also have the server-side token. Otherwise it is impossible to revoke the cookie without revoking everyone else on your system. This make it difficult to support the common situation where the cookie is stolen.

Regardless, I would strongly suggest you test your solution with common password managers, which may not interoperate with your solution correctly. It is very frustrating for an end user to get a user name from one place and the password from another and end up with them out of sync.