Session data & stay logged in

[freeloader]

At login, I set a session with the username of the user account in question:

session_register(myusername);
$_SESSION["myusername"] = $myusername;

 

At the top of each page I require a file called security.php, which contains:

session_start();
if(!session_is_registered(myusername)){
header("location:index.php");
}
$sql = "SELECT DTB_Users.Permission, DTB_Pages.Auth FROM DTB_Users, DTB_Pages WHERE DTB_Pages.Page = '".basename($_SERVER['PHP_SELF'])."' AND DTB_Users.Username = '".$_SESSION["myusername"]."'"; $result = mysql_query($sql);
if(mysql_num_rows($result) < 1) { exit ('No authorization level set for this page.'); }
$row = mysql_fetch_array($result); $Auth = $row['Auth']; $Permission = $row['Permission']; 
if($Auth > $Permission) { exit('You are not authorized to view this page.'); }

 

It's a bit of homemade code, you can probably notice It's doing its job and that's what important for me.

 

My question though is: how do I have it stay logged in? It gets logged out quite often at the moment.

 

I know a possible way would be to store username and an md5 hash of the pass in a cookie and match them before each page as a ways to set a new session if needed. But that doesn't seem like a very secure solution.

 

Are there better ways to do this?

 

Thanks in advance

[Psycho]

By "It gets logged out quite often at the moment" are you meaning that the user's session is expiring? I.e. they are inactive for a period of time?

 

Assuming your session information is being consistently handled across the application, as long as the user is active (within the session time out period - say 20 minutes), the user would only lose their session if they are inactive for the session time-out period. If that is not the problem, then your session handling is defective somewhere, maybe not loaded on a certain page. If that is the problem, then increase the session time-out period in the server settings.

[freeloader]

Yes, that was indeed poorly phrased.

 

I meant it gets logged out after the default inactive session timeout. I'd like to have a 'stay logged in forever' function, like this site is using for example.

[Psycho]

Yes, that was indeed poorly phrased.

 

I meant it gets logged out after the default inactive session timeout. I'd like to have a 'stay logged in forever' function, like this site is using for example.

 

Well, truth be told, the phrase 'stay logged in forever' is just as poor of a phrase and is a complete misnomer. There is no way to stay logged in forever - there always is a session length. The process would more aptly be called "log me in automatically and silently". The process works as you expected. Data is stored in a cookie. When a page loads if it finds that the user is not logged in it will then check for information in a cookie to log the user in. This is all done seamelessly to the user.

[freeloader]

I know that, hence the quotes. Well, in principle it can be done though, there is a way to stay logged in forever. You could force the server to not delete session information and set the session to last 'forever'. Problem is you'd clutter your system after a week with that. So in fact, there is no practical way of doing that.

 

I also know that the only way to re-authenticate the session is by storing the information in a cookie on the user's end. My question was though: what is the safest way to do this?

 

A possibility would be to store login and password hash in a cookie. This just doesn't seem secure to me. I'd rather work with some other kind of authentication token. However again: what is the best/safest way to do that?

 

Thanks in advance.

[Psycho]

I know that, hence the quotes. Well, in principle it can be done though, there is a way to stay logged in forever. You could force the server to not delete session information and set the session to last 'forever'. Problem is you'd clutter your system after a week with that. So in fact, there is no practical way of doing that.

 

Actually, I don't think that is possible in principle either. When you use sessions, the session ID must be maintained by the client. This is normally done by the system creating a cookie on the user's system with the session ID but can also be done by propogating the session ID in the URL. This is all handled by the server. And, that cookie has an expiration such that it expires as soon as the browser is closed. So, the session is not maintained.

 

But, I digress...

 

So, you want a way to automatically authenticate the user when they return to the site. The only way to do that is with a cookie. So, the question really is what do you put in the cookie and maintain security. As oing as the password hash is properly salted any risk is probably mitigated. But, I think a better approach would be to utilize the session even after the session expires. Here is the process you could follow:

 

Create a secondary table to maintain "offline" sessions. There would need to be two fields: userID and sessionID. After a user is authenticated create a record in that table with their userID and the current session ID AND save a cookie that does not expire with that session ID (this will be different from the session cookie). Let's call this the "Saved Session" cookie.

 

So, now, when the user attempts to access the site and you determine they are not already authenticated check to see if they have the cookie for the saved session. If not, they go to the normal log in page. But, if they do, then authenticate them according to the user ID associatied with that saved session. AND update that record and the cookie with the new session ID.

 

You would want to allow multiple saved sessions for a user in case they have multiple computers. So, one problem you would encounter is is a user deletes all their cookies. You will have orphaned data in that table. That may or may not be a problem depending on how often users delete their cookies and how many users and how much activity you have. Plus, a cookie could be copied to another computer.

 

There is also another twist that could aleviate the orphaned records and address the security issue. In additin to saving the userID and the session ID you could save a value that is specific to the computer being used (in the database, not the cookie). Using that value you could delete orphaned records and ensure the cookie can't be used on another PC.

 

I don't know what client specific values you can access via PHP if any. But, if you can't get them via PHP you could get them through a JavaScript workaround. Won't work in every instance, but then you just don't store a machine specific value in which case you are back to the original solution and it will still work.

[freeloader]

Re-authenticating based on same session id. That seems like a good idea.

 

As for password security, I agree, you wouldn't be able to read the password from that cookie. The only problem I have with that method is that when someone steals your cookies, they can log you in anytime anywhere.

 

As for cluttering the db, I don't think that would be much of a problem seeing there'll only be around 10 users for the time being. It's a closed platform. If however I do plan to expand it and allow more users, I could look into that a bit.

 

I think I'll just put the session id in my current user table. Since that is based on a primary key, it should not clutter anyway and it should only allow you to be logged in on one session at a time. Another method could be to add a latest activity column to the table and remove session after a month of inactivity to prevent cluttering.