mikhl Posted July 19, 2012 Share Posted July 19, 2012 Hello, When using sessions to give registered users acess to their content. What length of time do you think is a good length of time for a session to expire. Taking into account the user should be able to ask the session to never expire. If a users session does expire, what do you think is the best thing to do? Is it best to navigate them to the login page, or would it be better to prompt them with some sort of message popup saying something along the lines of "your session has expired, please enter your password to log back in, or click here to log in as someone else". Quote Link to comment Share on other sites More sharing options...
ignace Posted July 19, 2012 Share Posted July 19, 2012 I would use a cookie lifetime of 0 seconds, default setting. Removes the cookie upon browser closing. Only when they check a "remember me" of some sort would I change the cookie lifetime. session_set_cookie_params (needs to be called before session_start) allows you to change the cookie lifetime of a session. Quote Link to comment Share on other sites More sharing options...
ManiacDan Posted July 19, 2012 Share Posted July 19, 2012 Taking into account the user should be able to ask the session to never expire. If you're letting the user select expiration, why is this even a question? Do you just want to know what value to make the default in the dropdown? Sessions almost always expire when the browser window is closed. If you don't do that, you have session files hanging around on your filesystem on your server forever. The way amazon, facebook, and PHPFreaks do it is by having another set of cookies which will automatically log you back in and re-populate the session with certain chosen bits of data. The session itself dies when I close the window though. If a users session does expire, what do you think is the best thing to do? Is it best to navigate them to the login page, or would it be better to prompt them with some sort of message popup saying something along the lines of "your session has expired, please enter your password to log back in, or click here to log in as someone else". If their session expires, it's gone, so you don't know if it's expired or if this is their first time on your site. Just kick them to a login page. Quote Link to comment Share on other sites More sharing options...
mikhl Posted July 19, 2012 Author Share Posted July 19, 2012 If their session expires, it's gone, so you don't know if it's expired or if this is their first time on your site. Just kick them to a login page. I was thinking something along the lines of: when the user logs in a cookie containing the users id. When a page is loaded it will be checked to see if the session exists, if not, it is checked to see if the user id cookie exists, if so a request will be made for the user to log back in. Quote Link to comment Share on other sites More sharing options...
ManiacDan Posted July 19, 2012 Share Posted July 19, 2012 I was thinking something along the lines of: when the user logs in a cookie containing the users id. When a page is loaded it will be checked to see if the session exists, if not, it is checked to see if the user id cookie exists, if so a request will be made for the user to log back in. So all I have to do to break into your site is to delete my session cookie and change the userID cookie to someone else's user ID? Quote Link to comment Share on other sites More sharing options...
Jessica Posted July 19, 2012 Share Posted July 19, 2012 Considering he said in several places he would prompt the user to log back in, I don't think that would work, Dan. Quote Link to comment Share on other sites More sharing options...
ManiacDan Posted July 19, 2012 Share Posted July 19, 2012 Considering he said in several places he would prompt the user to log back in, I don't think that would work, Dan. Then what is the purpose of the user_id cookie? If it's just to pre-fill the form fields for login, then that's fine. It sounded like he was going to automatically log the user in just based on the ID in the cookie. Quote Link to comment Share on other sites More sharing options...
Jessica Posted July 19, 2012 Share Posted July 19, 2012 I would have thought so too, but he did say "a request will be made for the user to log back in." and "your session has expired, please enter your password to log back in, or click here to log in as someone else". I think he just wants to know if they were logged in before, rather than logging in for the first time. Quote Link to comment Share on other sites More sharing options...
xyph Posted July 19, 2012 Share Posted July 19, 2012 Why not just store the username, rather than the userid ? Save a request. Don't forget to remove any HTML special characters before outputting the value of the cookie! Quote Link to comment Share on other sites More sharing options...
mikhl Posted July 19, 2012 Author Share Posted July 19, 2012 Sorry if I caused any confusion with the saving the users Id in a cookie. This was just an idea I had and I was wondering what others thought about it. In retrospect, I would have used the username; it makes much more sense. To clear anything up, the cookie was being used to auto fill part of the lov in form. A way to. And it feel to the use like they are verifying their credentials, rather than actually logging in again. However, I am unsure at to if I will be implementing this approach into my website. Maybe it is taking a step too far for something that should be quite simple. Quote Link to comment Share on other sites More sharing options...
xyph Posted July 19, 2012 Share Posted July 19, 2012 It's a nice functionality for returning users, without being as insecure as actually keeping the session alive for an extended period of idle time. It wouldn't be much work to implement this. Quote Link to comment Share on other sites More sharing options...
Tarential Posted July 21, 2012 Share Posted July 21, 2012 On my own CMS, I have implemented a login cookie using the design protocol outlined here: http://jaspan.com/improved_persistent_login_cookie_best_practice I understand it to be a relatively secure way of doing things, but I would also welcome corrections if I made this assumption unjustly. Quote Link to comment Share on other sites More sharing options...
xyph Posted July 22, 2012 Share Posted July 22, 2012 If you're dealing with sensitive information, then I don't see a point to ever have persistent logins - even if the 'persistent session' is of lower privileges. If it's a forum, and account theft won't constitute a significant 'loss', then it may be an ease-of-use feature that's worth including. To summarize, if security is a priority, persistent logins are always a bad idea. To point out a few theoretical flaws in the system posted - Please let me know if I've made any mistakes - If an attacker can steal one cookie, he can probably steal them all. What's to stop the attacker from stealing the 'series identifier' ? - A legitimate user uses the 'remember me' feature on his laptop, as well as his desktop. When switching between computers, he will get you 'You are hacked' message, as only the laptop or the desktop will have the newest persistent token, but both will have the username and series token. - Why check against a username cookie? What benefit does this provide for persistent sessions? - A user still has to log in on a per-session basis to perform standard account activity. Though this help prevent against CSRF, it makes the whole 'remember me' option feel redundant. Quote Link to comment Share on other sites More sharing options...
xyph Posted July 22, 2012 Share Posted July 22, 2012 Oops, re-read the article. I understand now the series ID is meant to track individual locations, so the desktop->laptop issue, isn't an issue. So the second token is simply to inform the user of a possible persistent login hijack, the rest still applies though. It doesn't really add any extra security, IMO. Quote Link to comment Share on other sites More sharing options...
Christian F. Posted July 28, 2012 Share Posted July 28, 2012 I see that people are confusing their terms a bit. Session lifetime is not the same as cookie lifetime, even the session cookie. The browser can (and frequently does) delete the session cookie without the server deleting the session, or vice versa (though a lot more uncommon). What normally happens is that the server creates a new session, stores it on the disk and sends a cookie with a corresponding ID to the client. When the client is then closed, the cookie gets deleted from the "jar". However, the server does not know anything about this, and as such keeps the session alive and stored on disk. It's not until the session.gc_maxlifetime has been reached that the server will mark it for deletion. Before that time, however, it's entirely possible to manually craft the session cookie and resume the session. So, the questions are:Are we talking about the session cookie lifetime, auto-login features, or the actual maximum life time of the server-session? If the latter: Are you talking about how long the session will last after the last change, or since the user logged on IOW, forced logoff after a while)? If it's the session cookie lifetime, or auto-login features, then you've already gotten your answer. If it's the session maximum lifetime, then the situation becomes a bit more complicated. Usually, however, you're good to just leave it at default. Unless you encounter problems, or have any other specific (normally security-related) reasons for needing to change it. Quote Link to comment Share on other sites More sharing options...
ignace Posted July 29, 2012 Share Posted July 29, 2012 I see that people are confusing their terms a bit. If that was in reference to my post (I could not find any other post mentioning lifetime). Then, no I was not. I am well aware that a cookie may be long gone before a session is. And that it's possible to hijack this session if one can re-create the matching cookie. If no security measures are in place like a simple user-agent string check and/or ip-address check or any other measures. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.