Archive
Monthly
Go
|
|
DNN Blog
Jan
10
Posted by:
cathal connolly
1/10/2008 1:21 AM
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.
25 comment(s) so far...
Re: what doesn't "Remember me" work like I expect?
Cathal, EXCELLENT Explanation! That has been bugging me (pun intended) for a while. I can't tell you how many comments I've seen about it being a DNN problem but I now understand that it's not. I hope everyone reads this.
Thanks for all your efforts!
Chuck R.
By carizzio on
1/10/2008 3:34 AM
|
Re: what doesn't "Remember me" work like I expect?
If, yes a big if, somebody got my cookie, what could they access at dotnetnuke.com in relation to being a security issue?
By brian on
1/10/2008 3:34 AM
|
Re: what doesn't "Remember me" work like I expect?
Brian , if someone has your authentication cookie they effectively are you i.e. they're impersonating you, so anything you can do they can do e.g. post forum posts, edit your user details etc.
By cathal on
1/10/2008 3:36 AM
|
Re: what doesn't "Remember me" work like I expect?
Ok, I might be a bit of a newbie but..... most of the time the user details is useless anyway as my experience on dnn.com is that nobody ever uses them so if a hacker is good enough to know how to do this and has nothing better to do with their time than change my user details on dotnetnuke.com they can have at it - change my details to their hearts content.
And if this target starved hacker actually does post in the forums as me I simply post an explanation thread and change my password. Don't get me wrong I'm glad DNN is worried about security but in my opinion DNN is "cutting off their nose to spite their face" in that having to continuously login is a pain in the rear for your customers as MANY of them have said in the forums.
However, I really do appreciate the explanation blog Cathal! Since you are on a roll........ :) could you write a blog explaining DNN's position on the forum moderation? I have never understood this one either - seems to me it would be much easier to delete spam posts when they occur instead of approving every post. This is another "pain in the rear" for new community members who haven't been "trusted" yet.
By leazon on
1/10/2008 10:26 AM
|
Re: what doesn't "Remember me" work like I expect?
Leazon,
whilst some people have unique username/passwords for every site they're a member of, many reuse their username/password. If a hacker gains access to your cookie they could simply browse dotnetnuke.com as you, update your email address, request a copy of your password and then change the email address back to the original one. They now know both your username and password and can spend some time checking to see if this combination works on other sites such as amazon etc.
Whilst some individuals may not be concerned at their dotnetnuke.com details, many do, and we can only choose one setting, so we have to respect the majority of users IMO.
By cathal on
1/10/2008 10:48 AM
|
Re: Why doesn't "Remember me" work like I expect?
It is important to remember that Cookie handling applies to ALL users on the site. So while Brian and Leazon might not care if someone impersonates them, I think that the site administrator's might have a different view. Since there are a large group of individuals who have some level administrative privelege on the site, there are potentially a large group of potentially interesting attack points for a hacker. Also, many users do not engage in safe password practices and will re-use passwords from site to site. If a hacker gets your user account on DotNetNuke.com, they could change your email address, email themselves a copy of your password and then add that to a dictionary for later attacks on other sites.
By jbrinkman on
1/10/2008 12:26 PM
|
Re: Why doesn't "Remember me" work like I expect?
There is also a distinction that can be made between the cookie and the actual FormsAuthenticationTicket that’s stored in the cookie. Both have a property which governs expiration. While it is most common to use FormsAuthentication.SetAuthCookie, it is also possible to manually create the authentication ticket, encrypt it, and store this ticket in a cookie with the right name. This is basically what FormsAuthentication.SetAuthCookie does behind the scenes.
I believe what you ran into when trying to implement expiration using the PersistentCookieTimeout was that you were only setting the expiration on the cookie. The great news for DNN is that with PersistentCookieTimeout already in place, all you'll need to do is change the code in the UserLogin procedure in UserController.vb to manually create an authentication cookie. I'll work up a blog post with some sample code and provide the URL when I'm done.
By dworthley on
1/11/2008 1:45 PM
|
Re: Why doesn't "Remember me" work like I expect?
Here's the blog entry I created. Scroll down to where it says Code Alert to see how the UserLogin procedure in UserController.vb could be updated to make use of the PersistentCookieTimeout configuration option.
http://www.itcrossing.com/Blog/tabid/103/EntryID/14/Default.aspx
By dworthley on
1/11/2008 1:46 PM
|
Re: Why doesn't "Remember me" work like I expect?
@dworthley, that's an interesting distinction that I hadn't considered (i did know that the expiry of the "ticket" was stored as a part of the encrypted value). My understanding is that when the user revisits the site, the forms authentication code in the framework resets both the cookie and the ticket expiry, so your solution won't work. Please try to test it by visting multiple times. I'll put together some test code myself this weekend and see if this works.
By cathal on
1/11/2008 1:48 PM
|
Re: Why doesn't "Remember me" work like I expect?
@Cathal, I have been logged in for a couple days now to the DNN installation where I tested this feature with a PersistentCookieTimeout set to 5256000 and a forms authentication timeout of 1 minute. If I log out and log back in without the ‘Remember Me’ option, my ticket expires after 1 minute.
Also, I figured you were probably aware of the distinction and if you’re like me you may have tested this very scenario before but due to some strange permutation in the set of variables in your test environment have come to the conclusion that it didn’t work.
By dworthley on
1/12/2008 2:42 PM
|
Re: Why doesn't "Remember me" work like I expect?
@dworthley, I'll definately try that this weekend. One thing to note is the PersistentCookieTimeout works on the first return to the site after closing the browser, it's the subsequent visits it failed to work on - it was some time ago when i did this work and i had to rebuild my laptop due to alpha/demo/ctp problems, so it may be that you're correct and that my environment was not working as expected, i've love if this was the case and we could resolve this issue.
By cathal on
1/12/2008 2:44 PM
|
Re: Why doesn't "Remember me" work like I expect?
@dworthley, I'll definately try that this weekend. One thing to note is the PersistentCookieTimeout works on the first return to the site after closing the browser, it's the subsequent visits it failed to work on - it was some time ago when i did this work and i had to rebuild my laptop due to alpha/demo/ctp problems, so it may be that you're correct and that my environment was not working as expected, i've love if this was the case and we could resolve this issue.
By cathal on
1/12/2008 2:45 PM
|
Re: Why doesn't "Remember me" work like I expect?
@cathal, I should have mentioned that over the two days I was closing and re-opening the browser, so it may have been an issue with your original test environment. I too hope this works for you and we are able to get persistent cookies working again on the DNN site.
By dworthley on
1/13/2008 12:13 AM
|
Re: Why doesn't "Remember me" work like I expect?
@dworthley,
I've spent the afternoon testing this and your solution seems to work perfectly, so i'll be checking the change in shortly. It may take a while to show up as it's likely to be in the first cambrian release, which will require substantial testing due to the amount of change.
By cathal on
1/12/2008 6:24 PM
|
Re: Why doesn't "Remember me" work like I expect?
This will sound terribly noobish, but what do I have to do to get this feature working in my installation (4.7)? I cannot use the User Online module because it is inaccurate, and if I go into the web.config and change the timeout to 1 year, the online status never updates.
By 67RSSS on
3/5/2008 12:35 AM
|
Re: Why doesn't "Remember me" work like I expect?
Checking to see if there is a work around for this yet. I have version 4.8.2 and it is still not working without a change to the web.config file which will still cause the online status to not be accurate.
Has another solution been found?
By CreativeAnswers on
5/6/2008 8:06 PM
|
Re: Why doesn't "Remember me" work like I expect?
Well thats all fine and dandy. You learn something new everyday. The problem is, my users are submitting issues along the lines of they expect the "remember login" feature to auto-populate the "username" field in the login control, and I've got nothing to tell them other than they're out of luck.
By ptleitch on
5/6/2008 8:06 PM
|
Update?
Any word on how one could get this enhancement in 4.9? Or is it already there?
By Lucas Jans on
12/4/2008 1:57 PM
|
Re: Why doesn't "Remember me" work like I expect?
@Lucas Jans,
i dont believe it's in 4.9, you could download RC2 of dnn 5.0 and backport if you require.
By cathal connolly on
12/4/2008 1:58 PM
|
Re: Why doesn't "Remember me" work like I expect?
How about now? Any update? I keep searching, but cannot find anything current on this issue. Is there a simple answer as to how to get this working "as expected" yet? Thanks in advance - Jeremy
By Jeremy Farrance on
2/26/2009 9:13 PM
|
|
|
Re: Why doesn't "Remember me" work like I expect?
5.3 - not yet!
By Daniel on
7/1/2010 12:41 AM
|
Re: Why doesn't "Remember me" work like I expect?
@Daniel, actually this has been working as expected since 4.8.1 - www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/1784/a-new-solution-to-an-old-problem.aspx
By cathal connolly on
4/29/2010 4:14 PM
|
Re: Why doesn't "Remember me" work like I expect?
Using 5.6.2 and I believe it's every hour or so of idle time that I have to log back in. I assume if I can find the cookie field that says "60" minutes and increase it, I should be good. No luck finding such parameter. Anyone else?
By Kevin on
5/12/2011 4:10 PM
|
|
|
|