First a bit of background. There are two types of cookies, session (sometimes called temporary) and persistent cookies. A session cookie is one that automatically expires either when it hits it's expiration date, the user logs out or the user closes the browser. This last reason is the key one, as it means that once you close the browser you are safe from hackers stealing your cookie, either via physical access to the machine or via another method such as a cross-site scripting (XSS) attack. Even if a hacker get's a copy of your cookie before you close the browser/log out, the expiration period is so short it's usually not of much use to a hacker i.e. by the time a hacker comes to use it it's passed it's expiration date.
Persistent cookies also get deleted when their expiration date is reached, or a user logs out. However they do not get expired when the user closes the browser, making them useful for users who want data to persist over multiple browser sessions e.g. you may want to log into a site once and have it automatically recognise you when you return over a number of hours, days, weeks or even years. With this convenience comes a greater risk, as if a hacker gets a copy of your cookie they have a lot longer to use it - this is why sites that take security seriously such as commerce or banking sites will often not allow the use of persistent cookies (note: we'll be checking in a change to dotnetnuke to allow hosts and portal admins to remove the "remember me" checkbox to provide for this common request).
As there are benefits and drawbacks to both types of cookie, many sites like to allow their users the option of session or persistent cookies, usually via a mechanism such as a "remember me" checkbox. This allows the users to decide between the security of a session cookie or the convenience of a persistent cookie.
So, enough cookie background, I still haven't answered why remember me doesn't work as users often expect. I first commented on this a few years ago (http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/233/Default.aspx), but perhaps an example would better explain.
How forms authentication cookies worked under asp.net 1.1
session cookies expiration = current datetime +the forms timeout value e.g. 60
persistent cookies expiration = current datetime + 50 years
e.g.
If a user logs onto a site at 13:00 1st Jan 2008 and doesn't check the "remember me" checkbox, their authentication cookie is created with an expiration date of 14:00 1st Jan 2008. If the user browses for 10 minutes and then goes to another site the cookie will automatically expire at 14:00 (or whenever they close their browser).
If a second user logs onto a site at 13:00 1st Jan 2008 and checks the "remember me" checkbox their authentication cookie is created with an expiration date of 14:00 1st Jan 2058 -this cookie will not expire until the user explicitly clicks the "Logout" link or else deletes the cookie from their browsers temporary internet files.
Obviously having a 50 year expiry date for persistent cookies was a crazy choice, so Microsoft decided to address this in asp.net 2.0. Unfortunately they proceeded to make another unwise choice. Rather than hardcoding the value, they now read the forms timeout value to use to create the expiration date, meaning the same value was used for two different types of cookie.
How forms authentication cookies work under asp.net 2.0
session cookies expiration=current datetime +the forms timeout value e.g. 60
persistent cookies expiration= current datetime +the forms timeout value e.g. 60
If a user logs onto a site at 13:00 1st Jan 2008 and doesn't check the "remember me" checkbox their authentication cookie is created with an expiration date of 14:00 1st Jan 2008. If the user browses for 10 minutes and then goes to another site the cookie will automatically expire at 14:00 (or whenever they close their browser).
If a second user logs onto a site at 13:00 1st Jan 2008 and checks the "remember me" checkbox their authentication cookie is created with an expiration date of 14:00 1st Jan 2008 -this cookie will not expire until the user explicitly clicks the "Logout" link or else deletes the cookie from their browsers temporary internet files.
So we can easily see that Microsoft's "fix" broke the working of persistent cookies (this is the reason for site's that appear to ignore the "remember me" checkbox). So, an easy fix would seem to be to simply give a more generous forms timeout value e.g. 10080 (60*24*7=1 week), however there is a major drawback to this.
Now If a user logs onto a site at 13:00 1st Jan 2008 and doesn't check the "remember me" checkbox their authentication cookie is created with an expiration date of 13:00 8th Jan 2008. If the user browses for 10 minutes and then goes to another site the cookie will not expire as it still has an expiration date of nearly a week away, meaning that unless the user explicitly log's out or closes the browser the cookie will "live" for a lot longer than before.
If a second user logs onto a site at 13:00 1st Jan 2008 and checks the "remember me" checkbox their authentication cookie is created with an expiration date of 13:00 8th Jan 2008 -this cookie will not expire until the user explicitly clicks the "Logout" link or else deletes the cookie from their browsers temporary internet files.
So, with asp.net 2.0 the problem is that users who want the enhanced security of session cookies no longer get it i.e. they're effectively treated the same as persistent cookie users. Whilst session cookies will be cleaned up if the user closes the browser, this greater timeout period gives people with physical access to a machine more opportunity to steal the cookie (e.g. if you step away from your computer for a few hours with the browser still open the cookie doesn't expire), but more importantly if a hacker can perform an XSS attack on you, when they grab a copy of your cookie, they now have a week to use it to impersonate you/steal your data etc., rather than 60 minutes as before.
Obviously this is not acceptable for a great many sites. At dotnetnuke.com , we do use a larger timeout value, but we're also pragmatic and keep it at 1 day, rather than a much longer period -seeing this as a reasonable balance of security and convenience. We've looked at resolving this issue via code e.g. the PersistentCookieTimeout value in the web.config was one attempt that would provide separate values for session and persistent cookie timeout's, but unfortunately when a user revisit's a site the forms authentication code in the .net framework executes before any custom code, resetting the expiration date and making it impossible to preserve the initial expiration date. Another option would be to store a value for each user's desired expiration date upon first authentication, as well as storing a user's ID in another longer lasting cookie, and then use that to automatically log the user back into the system if the forms auth cookie is expired, but the requested expiration date hasn't been reached, but a system like that has a performance overhead as well as being a risk as auto-login security systems are popular with hackers :)
For now, we've no plans to build any hacks for this (though i'm open to suggestions , email them to security@dotnetnuke.com), instead it's up to the judgement of site owners to decide what value for timeout's they're comfortable. Ideally, Microsoft will eventually wake up and fix this flawed design (perhaps .net 4.0?) and we can finally please both those who want security and those who want convenience.