Remember me vs. persistent session for web applications

Question

This question is intended to gather information about what the specific security advantages/disadvantages are to using a "remember me" function for an online web site relying on sessions compared with making the session persist for long periods of time.

While the session may be used to store more data than just the identity of the user, this the only information required to be propagated between interactions by the "remember me" functionality.

In both cases, the state would be represented by information stored in a cookie on the client. The session is identified by a random value used to reference data held on server-side. The "remember me" function might be implemented purely using data stored in the cookie or by a handle to the serverside data as per the session (some comparison of the variants for "remember me" are described here in relation to sessions).

Answer 1

The main risk of a persistent session is increased exposure for any existing client-side vulnerabilities (e.g. XSS, CSRF, session fixation, etc).

That is, any malicious site targeting your users through exploits for the above would be more likely to succeed because the user is left logged in.

With remember-me the above could apply too - Say the long-term remember-me token is exchanged for a session token automatically per request.

e.g.

in the request the browser sends

Cookie: remember-me=32132213312132

and the server automatically issues a session token for this request because the token validates. It also replies with their new session token for subsequent requests to use in this session:

Set-Cookie: session=asdkalkjdjsaddsajdsal

This shows that even though a separate cookie is used for long term access, because it is automatically exchanged it will also aid cross-domain exploits in attacking user sessions.

You could mitigate this by using OAuth2 style refresh tokens. Then if the attacker tries an CSRF attack such as

<img src="https://example.com/transfer_money?to_acc=2321321&amount=1000000" />

it would not automatically succeed because the refresh token alone is not enough to authenticate the request (remember-me) - it must be exchanged for an access token (session).

e.g. if the user visits your site, there could be another explicit step to get the session token to represent an active, logged-in user:

<form method="post">
  <input type="hidden" name="anti-csrf" value="asddadaddasa242421fsas" />
</form>

The anti-csrf token is attached to the refresh token in the server-side database, preventing a CSRF exploit from being used to get the token ahead of the attack. The above should be manually submitted by the user to prevent an attacker from opening the page in a popup or within an IFrame.

Only after all of the above validates does the server reply with an access token (session):

Set-Cookie: session=asdkalkjdjsaddsajdsal

Of course your site should already mitigate against XSS, CSRF and the like, however this is a defence-in-depth approach to guard against long term tokens being set that have a higher chance of compromising a user because their login is more likely to be active should they be attacked.

Answer 2

(I already had some thoughts on the matter but was seeking further opinions. Since I seem to have caused some confusion, setting them out here may help in understanding the problem I am trying to address).

There are very definite functional impacts, particularly if the developer chooses to use the session substrate for storing transactional information, but that has other complications too. The functional impact is off-topic here.

The first argument in favour of a remember-me function is that it enforces a refresh of the authentication status. Although not an essential requirement of implementation (nor an essential exclusion from the complementary persistent session) it does mean that the account should be re-validated when a user resumes interaction after a break.

As per the comments above, Limit has already noted that user consent is critical. Leaving a public access terminal logged into an account would not be a good idea. This therefore means that simply extending the lifetime of the session is not an option - the system must implement the choice of the user. Architecturally, the "remember-me" option is less entwined with the session management making it simpler to implement and therefore safer.

A further consideration is that, in the case of long-lived sessions, the information required to take over those sessions is stored in the backups. This is also true when the "remember-me" cookie contains a reference to server-side data.

If the "remember-me" content is self contained data, suitably protected by cryptographic means, then anyone with access to a copy of the server data still has an extra hoop to jump through in order to access a session - i.e. they need to reproduce the crypto used to created the client side data. Of course, if they happen to have access to the code as well, then they likely will have access to any key, but this will have limited value if the key is derived from other constrained data such as the client IP address. On the other hand, arguably the same protections could be applied to the session id in a persistent session.

The next consideration is the content of the session data. If there is more than the account identity and authentication state (e.g. data integrated from other services) then it may have some intrinsic value to an attacker. In this scenario, reducing the yield by removing the data for inactive users (i.e. the "remember me" option) has some benefit.

Overall, I'm struggling to see any positive argument for the persistent session approach from a Security point of view.