Why remember me token?

Question

While implementing the "remember me" feature for a website, why do we complicate things and have a token called remember me token apart from a session token.

To the best of my understanding, remember me token can be used to login and create a new session token while the session token only lasts for a few minutes or till the time the user closes the browser. Why can't we increase the expiry duration of the session token itself to the desired time till which we want the user to be logged in?

I have a need to implement such a functionality in a flex based application running over tomcat and I wondering the need of remember me tokens

Also, is it possible to get this functionality out of the box within tomcat?

Opiate

Answer 1

1) Sessions typically contain a whole bunch of data other than the user's login name. Therefore, if you just set the expiration date to a few weeks or months like a remember me token, you'd probably run into performance problems on the server due to thousands or millions of heavyweight session objects.

2) Remember tokens are client-side, not server-side. This puts all of the storage requirements on the user's browser, which is a better solution for simple data like login names. If you relied on session ID's linked to in-memory objects on the server, then every time you restart your server or the server process (to deploy an updated application, for instance), then all of those session objects would be lost.

Bobbybobbye

Is it possible to seemlessly integrate Spring Security to your flex application without affecting the client code? – Opiate

I have no clue how to integrate my flex application to Spring security to use its Remember me feature, is it possible to do so. – Opiate

I don't know, I don't use Spring or Flex. – Bobbybobbye

Answer 2

Because by definition, a session ends as soon as the user closes his or her browser. Thus the session cookie will expire as soon as the browser is closed.

Since the purpose of remember-me functionality is to keep the user logged in across sessions, the information stored in the remember-me cookie must persist across browser restarts.

To get this functionality "out of the box" look at using a framework like Spring Security.

Herniorrhaphy

if we add the expires clause in session cookie, then it can be made to last for any number of days, what's the harm in that? Is there any specific reason for writing a complicated mechanism of having two different tokens? – Opiate

Answer 3

Remember-me cookies usually store the username and some kind of token. Both of them are used to authenticate the user. Take a look at Improved Persistent Login Cookie Best Practice which describes the process quite good.

The session cookie is used to store a session ID on the client which allows the server to recognize a session an load the session data that is associated with the session.

So remember-me cookies have a longer life time (usually days or weeks) than session cookies. Session cookies usually expire after a few minutes or when the browser is closed.

From the top of my head there are a few reasons why two different cookies are used:

• If only the persistent remember-me cookie would be used the server would need to authenticate the user with every request. When an additional session cookie is used the server doesn't have to do this as long as the session is valid. Of course the session ID could be stored within the remember-me cookie, but what's the point in doing that?
• From a coding point of view it's better to reuse the existing session mechanism. Why reinvent the wheel instead of just adding a feature (authentication via remember-me cookie) that can be enabled/disabled easily?

Gentility

but what I fail to understand is why can't be extend the life of a session cookie when we require longer sessions. I tried adding a servlet filter which adds expire clause to a session cookie and thus increases its expiry duration. I could not see the harm in using such an approach which is quite convenient for me instead of building a completely new mechanism of introducing a remember me cookie in my application. If I add a remember me cookie, then I need to make a number of changes to my application – Opiate

So, I guess you are not using Spring Security or even the combination of BlazeDS, Spring Security and Spring BlazeDS Integration on your server, are you? Those could provide the remember-me functionality out of the box. If you really change the expiry date of the session cookie don't forget to configure the session timeout on the server as well. Otherwise the server could invalidate the session too soon. – Gentility

I am only in the evaluation phase, I have a blazeds application where I am trying to implement authentication. Adding expiry to session cookie appeared to be an easy option, whereas I am not sure if spring security can easily work with a blazeds application including its remember-me feature – Opiate

Take a look at Spring BlazeDS Integration. The latest version added support for the remember-me feature from Spring Security. So, it allows you to use Spring Security and BlazeDS and with a little bit of Spring configuration everything should work out of the box. – Gentility

Answer 4

People have correctly said that the session contains a number of heavy weight objects. With enough users on your system, if you try to keep them all in the finite amount of memory that the server has, eventually you will crash the server when that memory max's out.

I worked on a project one time where a production code update had a memory leak. It was a J2EE project (yes J2EE not Java EE). When a user logged in to check their invoice at this phone company the user session was not released properly from memory (I can't remember the cause but that was definitely the issue). This bug mimics what you are asking about doing on purpose.

The server kept crashing. So we put a profiler on it. We would watch the memory use go up through the day until it topped out and shorty after the app server crashed. We added memory and increased the VM memory setting. I told them it was a memory leak but because I wasn't a $200.00/hour "server expert" people were unwilling to believe it because the people who were there still believed that the garbage collector was all powerful instead of being just very good.

Two days later (it affected the "view your invoice" system, not the main business system, i.e. it didn't have the same workload or memory requirements even though it had plenty of hardware memory in the servers), they hired a couple of $200.00 per hour consultants who after a day told them the app had the aforementioned memory leak. It was fixed and all was good... minus the consultants fees.

In any case here is the take away from this: if you don't end user sessions when users log out or close their browser (session time out), you run a real risk of maxing out your memory and crashing your servers. Especially if your site or app has any significant number of users. As mentioned by others, lightweight tokens/cookies are best.

Yaws

Answer 5

The reason for why we should use another cookie other than the sessionId cookie to remember the user is not because sessions should expire fast or you'll face performance problems on server.

Jetty (And probably many other servlet containers) has a feature that enables automatic eviction of idle sessions from memory to disk or database which IMHO rules out all the above justifications around performance problems that comes with storing heavyweight sessions in memory.

The reason another cookie is used is that remember-me is to remember the user even after the session has expired. So if user's session has expired, the other cookie is used to authenticate the user without them having to enter a password, which obviously makes phishing attacks less likely. Although there are disadvantages to it as well, for example if someone gains access to your laptop and steals your authentication tokens would be able to impersonate you, unless the server applies even more security measures to bind the token to your client and location only.

In short, remember-me is an authentication mechanism and not a replacement for session cookies.

I believe it is fine to have long term session expiration dates as long as they are stored out of memory. And once they expire, simply ask for password. Many websites offer this feature as "Remember me for 30 days" which is achieved just by using a long term sessionId cookie, nothing else.

Carlstrom