Logged on users and their sessions

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".

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.

Taking into account the user should be able to ask the session to never expire.

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.

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.

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.

Considering he said in several places he would prompt the user to log back in, I don't think that would work, Dan.

Considering he said in several places he would prompt the user to log back in, I don't think that would work, Dan.

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.

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!

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.

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.

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.

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.

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.

• 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

1. Are we talking about the session cookie lifetime, auto-login features, or the actual maximum life time of the server-session?
   
2. 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.

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.