How do you make the login session last longer?

[keldorn]

I have a button that says "remember me", if this is checked, I will check with isset for it, then will want to extend the lifetime of the session, how is that possible?  I know with $_COOKIE you can set like  1 week etc. But with $_SESSION how?

[PFMaBiSmAd]

To extend the lifetime of a session, you must both set the session.cookie_lifetime and the session.gc_maxlifetime to the longer value. However, you must also set the session.save_path to be to a private folder so that only your session settings will affect your session data files. All these settings must be set before every session_start() statement, so it is best to set them globally in the master php.ini.

 

A session is designed to last for one browser session (hence the name.) A remember me feature is usually done using a regular $_COOKIE instead of modifying how sessions work.

[keldorn]

A session is designed to last for one browser session (hence the name.) A remember me feature is usually done using a regular $_COOKIE instead of modifying how sessions work.

 

 

What I could I store in the $_COOKIE that would allow the application to verify the user again securely, then automagically login them in again with a new $_SESSION?

[PFMaBiSmAd]

Generate an md5() hash of a uniqid for each user and store that in the cookie and in a column in your user table - http://us3.php.net/manual/en/function.uniqid.php

 

This is essentially what a session ID is, except the value in the cookie will point to the correct row in the user table instead of pointing to the correct session data file.

[keldorn]

Ok now how about security? Someone could steal the cookie, then put it into their browser and be logged in. Doesn't sound too secure.

 

Maby put a warning beside the remember me " warning this will make your login less secure". xD

 

[PFMaBiSmAd]

Ok now how about security? Someone could steal the cookie, then put it into their browser and be logged in. Doesn't sound too secure.

 

That is exactly the same as what can happen to the session ID. If I get one of your user's session ID (being passed back and forth between his browser and your server, say over an unencrypted wireless Internet connection), I can visit your site and supply that session id and appear to be the actual visitor.

 

If you truly expect a login to be secure, within the scope of what you have control over, you must use HTTPS/SSL to encrypt the connection all the way between the browser and the server. However, this does not protect against a virus on or someone with physical access to the user's computer getting the session id or value in the cookie and impersonating the user.

 

You can protect against someone impersonating the user when the user has logged out by depending on a value stored in the user table that indicates the logged in/out status. If upon logout, the value in the user table is changed to logged out, even if someone gets a hold of the session id/cookie value and impersonates the visitor, they cannot log in unless they also supply the correct username and password. Too many people depend solely on the existence of a value in a session or a value from a cookie to determine that someone is logged in. The existence of a value in session or in a cookie should only identify someone. You then take that identifying piece of information and lookup in your user table if they are logged in and determine any other permissions they have on your site.

 

You must also record and check the USER AGENT and IP address information (they won't change during a single login period) and either of them does change due to the visitor switching browsers or doing something that would cause his computer to get a different IP address, he will just need to log in again.

[gizmola]

The other thing about sessions, is that they get cleaned up based on the amount of people using the site, and some arcane variables in the php.ini.  It's best not to have a mix of sessions --- have your settings be the best fit for your website and stick with that.

 

People often get confused about the difference between a session and a login -- they are not the same.  A login is an application state on your site.  It often gets facilitated by sessions, but the best way to think of it, is that every visitor is most likely going to have a session started, whether they have sucessfully authenticated themselves or not. 

 

A  "remember me" function can be many things, but one of the best solutions is to do as PFMaBiSmAd recommended and set a completely seperate cookie variable that indicates that they would like your site to bypass the normal name/pw authentication.

 

So clearly what you need to do to facilitate this, is add code that looks for the presence of the cookie, matches the person up, and in essence authenticates them.  For this reason, a hash is a good solution, because it should disclose nothing about the user.  For this reason a good md5() or sha1() hash of your construction will do the trick, but additionally, you need to alter your user table, so that this hash can be used to lookup which user it pertains to.

 

The hash in essence becomeas a SUBSTITUTE for the user entering the name/pw.

 

Now the topic of the relative security of this approach was brought up before, however you have to realize that sessions by default use cookies as the enabling technology (which is actually preferred in most cases), so a person getting their hands on a cookie file, is instantly able to masquerade as a user.  This isn't really as bad as you think, because again, it is no different than if someone was to look over your shoulder and watch you type your username and password.  As pointed out, unless the entire login is protected via SSL, anyone sniffing traffick will be able to see your name/pw in clear text, but in many applications this is

 

The issues involved have a name:  "session fixation".  You can read up on this problem, and potential solutions.  Best practice is to regenerate session ID's whenever a user attempts to "escalate privileges", and this would include a user wanting to change their password, or advance to an admin role, or whatever else you deem risky.  It also explains why changing a password typically involves requiring the user to enter their existing password first.

 

 

[keldorn]

That is exactly the same as what can happen to the session ID.

 

Right how could I forget that. My logic is not working great today. 

 

So does this sound like a good method?

 

User logs in -> Save Ip address in Session and also their row in the database

If remember me -> also save a unique id in the table and set a cookie with this unique id and their IP, which is md5 hashed. (I suppose too you can put a salt on them also.)

During browsing -> Check that session IP always is thier remote IP ELSE log them out

No session -> Check for a cookie , then grab the data from row with their cookie unique id and also check that the IP stored in database == their remote IP.

 

 

 

 

 

[gizmola]

Right how could I forget that. My logic is not working great today. 

 

So does this sound like a good method?

 

User logs in -> Save Ip address in Session and also their row in the database

If remember me -> also save a unique id in the table and set a cookie with this unique id and their IP, which is md5 hashed

During browsing -> Check that session IP always is thier remote IP ELSE log them out

No session -> Check for a cookie , then grab the data from row with their cookie unique id and also check that the IP stored in database == their remote IP.

 

Most of that sounds ok -- only the IP is an issue.  IP is dicey, because with big ISP's IP's can change.  You certainly wouldn't want to make sure that the IP is the same with remember me, as 99% of your users will no doubt have dynamic IP's that can change from day to day or hour to hour, depending on the ISP and their behavior.

 

What does make sense is that, if you want to implement this checking, you can see whether or not the IP address has changed for an active session.  The very presence of the remember me feature, will however, in essence need to disable the check, since remember me needs to supercede checks inside the session, and reset the internal authentication state, which would need to include the last IP.

[Daniel0]

[...] as 99% of your users will no doubt have dynamic IP's that can change from day to day or hour to hour, depending on the ISP and their behavior.

 

It's funny, I keep hearing things like that, but never in my life have I experienced an ISP here with dynamic IP address allocation if we disregard the dial up era.

[keldorn]

[...] as 99% of your users will no doubt have dynamic IP's that can change from day to day or hour to hour, depending on the ISP and their behavior.

 

It's funny, I keep hearing things like that, but never in my life have I experienced an ISP here with dynamic IP address allocation if we disregard the dial up era.

 

Yeah, my IP changes like 3 times a year. I think with the advent of IPV6 this will not be problem, every device should have a static IP address in the next few year that changes like once a year or never. lol

 

 

 

 

[gizmola]

[...] as 99% of your users will no doubt have dynamic IP's that can change from day to day or hour to hour, depending on the ISP and their behavior.

 

It's funny, I keep hearing things like that, but never in my life have I experienced an ISP here with dynamic IP address allocation if we disregard the dial up era.

 

This is quite common in the US.  Sadly there are still lots of people using Earthlink and AOL, not to mention people at corporations who sit behind a proxy.  Just a case in point, I have multiple friends here in LA who have Verizon DSL.  The router does a CHAP auth, and the lease on the IP is set so that they have to reauth every so often, and whenever it does this, the IP changes.  It's not at all unusual for people to get broadband here, and plug directly into their PC.  These people often turn off their equipment every day, and the result is -- new IP.

 

My mom has Comcast cable modem, and her IP stays the same for months at a time, but if the cable modem is reset, the IP changes.

 

With that said the biggest reason that IP's need to be looked at carefully is that ubiqitous NAT means that many users can have the same IP. 

[keldorn]

This is quite common in the US.  Sadly there are still lots of people using Earthlink and AOL, not to mention people at corporations who sit behind a proxy.  Just a case in point, I have multiple friends here in LA who have Verizon DSL.  The router does a CHAP auth, and the lease on the IP is set so that they have to reauth every so often, and whenever it does this, the IP changes.  It's not at all unusual for people to get broadband here, and plug directly into their PC.  These people often turn off their equipment every day, and the result is -- new IP.

 

 

Yes. So how about subnets?  A subnet like 67.159.0.0/18 can have like (255 * 255)  = 65,025 IP addresses to go around. Its likely their ISP wouldn't change their IP to far in this range. If they even have that many IP addresses. Specially people at corporation behind proxies, are likely to have only maby a very small range like

67.159.54.0/24

 

Say your a visitor logs in their IP is  67.159.44.33, they come back the next day, now their IP is 67.159.1.33

 

How about saving just the first notations of the IP (67.159)?  This certainly would narrow down session hijacking. This would require now the imposter  to have an IP on the same subnet. Although not offering full protection, its another layer.  The only problem I can see, is the IPV6 addresses which are coming out. You would have to make your login mechanism work for both. IPv6 are longer and more complicated, you probably will have to do a lot reading on the ipv6 to understand it.