[ACCEPTED]-Why remember me token?-jsessionid

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

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

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

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

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

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

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

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

From the top 2 of my head there are a few reasons why two 1 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?

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

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

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

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

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

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

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

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

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

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