Jump to content

Recommended Posts

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

 

 

Link to comment
https://forums.phpfreaks.com/topic/265951-logged-on-users-and-their-sessions/
Share on other sites

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

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.

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?

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.

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.

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.

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

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.