session problem

[jimfog]

This is the code that redirects the user if a cookie is found in its system:

if(isset($_COOKIE['cookiename']))    {    header("Location: adminmember.php");}

The code works, the problem is that when the user reaches the above page session is useless because not a variableis assigned to the session array, and that happens because, the code which does that, is located in index.php and it IS SKIPPED if the cookie is found. The redirection code above is found in index.php,if a cookie is not found, then the login form appears along with code the assigns the username to the session array,if the form is successfully completed. But all of the above is skipped(if the user is a returning visitor,something that is tested with the code in the beginning of the post), so no variable is assigned to $_SESSION. What can I do fix it?

[niche]

Force at least a null value at the beginning of each session. Otherwise you'll have to change your code. You can't have a script that skips important code.

Edited September 24, 2012 by niche

[thescientist]

your code can't compensate for a returning user? The whole point of remember me functionality is that you can restore the users state (for the most part) if the COOKIE is set. Typically that would involve pulling their username out of the cookie, and some sort of authentication token to check against to make sure they are the correct user.

[niche]

Well said scientist. Jimfrog, please post more of your code so you can get an answer.

[birbal]

when you check a existance of cookie you check that token against database like thescientist said. and prepare session data at same place if credentials match, before the redirection. remember cookie is set that does not mean that the user is authenticated.

[rahultailwal]

The thing is if cookie is set you will again set the session variable and then redirect to the main page. No need to login again. And if cookie is not set it will go to login page. Simple

[jimfog]

when you check a existance of cookie you check that token against database like thescientist said. and prepare session data at same place if credentials match, before the redirection. remember cookie is set that does not mean that the user is authenticated.

I am trying, to do this now, just I want some help on the coding

The thing is if cookie is set you will again set the session variable and then redirect to the main page.

Exactly right, this is what I am trying to achieve Here is some code-not all of it, do not want to overload you with code that might not be useful in our discussion:

    if(isset($_COOKIE['cookiename'])){header("Location: adminmember.php");}    if(!empty($_POST['remember']))	 {$timestamp=time();	 $identifier=uniqid();	   uniqid_to_db($identifier,$timestamp);	  setcookie('cookiename', $identifier, time() + 60 * 60 * 24 * 7);   

The first if statement checks if the user's PC has a cookie and then redirects,of course, here the code for checking the credential is missing(with the database) plus that it does not assign a value to the session array so that it can be transferred to adminmember.php. The second if statement just sets a cookie if the user has checked the "remember me" option in the login form(not shown here).I just need to set a session variable based on the user's name in that first IF statement so that this can be passed later to adminmember.php. The above implies "pulling" the username from the cookie, for security reasons though, I have not placed the username in the cookie, just a random number.It seems that using a hashed username in the cookie, and checking it against the db, is the only way to achieve what i want-and having the session work in adminmember.php. Comments;.

[rahultailwal]

the process could be, as i think, 1. Basically the remember me feature is for the users using their own system. No one else touch their computer system. Then their is no security issue.2. As i think the username and password both are saved in cookie in encrypted manner.3. After user browse page again, then cookie will be checked first with the database verification either valid or not.4. If valid then session variable will be set for that user.5. if he logout then all the cookie will be deleted again.

[birbal]

you need both username and a key (remember me token) to autologin user. you can encrypt your username and prepend or appened or mixed up in the key (key is hashed key). username=jimfogencrypt username= SOMEENCRYPTEDJIMFOGkey= hashedkeyoftokenotherthanpassword key which will be set as cookieSOMEENCRYPTEDJIMFOGhashedkeyoftokenotherthanpasswordorhashedkeyoftokenotherthanpasswordSOMEENCRYPTEDJIMFOGorslice and mixup the string to prepare different key what you will do is when remember cookie is set you need to take out the encrypted username and decrypt it and check that username and key combo in database. if match found pull all of user data and initialize session as authenticated user. hash is one way encryption. so you cant get back user name from hashed username which you will store in cookies. the problem with random number with remember me key is number has low entropy than alphanumeric hashes. means easier to guess.

[jimfog]

Ok...so the value of the cookie(as I understand) will be an encryption of the username plus another hashed key.And I am going to compare this with the username in the database, I suppose the username will be maintained in the db in a regular form-non encrypted. The next question is this:How am I going to pull the username from the cookie, which as you said must be encrypted?How am I going to decrypt the username that is found in the cookie? Example here would be better. I am describing above the first step of the whole process, but let us focus on it for now.

[birbal]

first you will extract the characters of encrypted username. how you will extract will be same way you did compact it. the hash of key length is fixed. so if you append or prepend the encrypted username you know already where to slice the string to get apart the encrypted username and hashed key. once you extract it you need to decrypt it. when you decrypt it it will be same as plaint text username as you have in your database,for encryption and deycrption you need to use mcrypt http://php.net/mcrypt

[jimfog]

Οκ...I will proceed with the code and If I am stuck I will post here again...thanks.

[jimfog]

Since we will be using the username after all I have to make the following question. Now, I am using a table named users where I store relevant info(password etc...) From the above discussion I understood that a table must exist where the cookie data will be compared with the table data where the username will be stored. SO, in essence, we are talking here 2 tables having the username-or is it maybe better to have a foreign key(in the table against cookie data will be compared)that will point to the username table? This question, relates to the db schema I should follow to achieve what I want.

[birbal]

storing it in user table should be sufficient. as each user can have only one remember token (if you are planing to remember user in only one machine)

[jimfog]

storing it in user table should be sufficient. as each user can have only one remember token (if you are planing to remember user in only one machine)

So, let me if understood correctly-and please say so-the key/random number of the cookie, should be stored you are saying in the user table, where also the password is found.

[justsomeguy]

That's fine if you want the user to have a single persistent session on a single computer. If they have multiple persistent sessions then you need a separate table. And make sure to not store the plain-text random token, since it is password-equivalent in allowing access to your system then it needs to be stored as a hash.

[jimfog]

If they have multiple persistent sessions then you need a separate table.

What do you mean multiple persistent session-can you give an example please when this can occur.

And make sure to not store the plain-text random token, since it is password-equivalent in allowing access to your system then it needs to be stored as a hash.

Regarding the token, this is going to be generated by the uniqid function(that is my intention-probably)-this, by definition is NOT plain text, unless you are suggesting that I hash it ANYWAY.

[justsomeguy]

What do you mean multiple persistent session-can you give an example please when this can occur.

Persistent logins on more than one computer.

Regarding the token, this is going to be generated by the uniqid function(that is my intention-probably)-this, by definition is NOT plain text, unless you are suggesting that I hash it ANYWAY.

That is plain text. The value in the cookie cannot be the same as the value in the database. The value in the database needs to be hashed, the value in the cookie can be encrypted also. The token is password-equivalent, it lets people access your system the same as a password, so you need to treat it the same as a password. Your passwords aren't stored in plain text and the tokens need to follow the same security principles. If someone gets access to your database you don't want them to have a bunch of plain text password-equivalent tokens that they can use to create cookies with. The fact that the token is composed of pseudo-random characters does not mean it is not plain text, it is plain text unless you encrypt or hash it.

[jimfog]

Your explanation about the token was very good. I just want to focus a little on the multiple persistent sessions issue.What is the rule of thumb today, should I design the persistent login mechanism(meaning a separate table in the database) taking into considerationthat the logins will be taking place in more than one computers. I have not the slightest clue about the above...What is your personal opinion?

[justsomeguy]

If you need unlimited sessions, you need a separate table. That's about all there is to say about that, if you're storing all of the data in a single row in the users table then you're limited by how many sessions you can track at once.

[jimfog]

I need to say one last thing about the random number placed in the cookie.I think it must come from the username(hashed of course) so that I can use it to start a session(passing the username to the session array). I think this is the way to go, if the page where the user is redirected(after a cookie is found)must have session data in it.

[justsomeguy]

The cookie token should not be based on the username, it shouldn't be guessable if you know the username. It should be random, unrelated, and associated with the username in the database. The username should be in the cookie either encrypted or in plain text (not hashed), the cookie should contain the plain-text token, and the database associates usernames with hashed tokens. I've pasted a reference to this a couple times, but if you're not following a guide like this then you should be. http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/

[jimfog]

.... in plain text (not hashed),

I think that would be dangerous, IT MUST be encrypted.

[jimfog]

what you will do is when remember cookie is set you need to take out the encrypted username and decrypt it and check that username and key combo in database. if match found pull all of user data and initialize session as authenticated user.

I assume the key-hashedusername combo will be in one column in the database.

[birbal]

no, only stores the key in database. as you have already a username column separatly already. the combo will be stored in cookies only. php will split the combo to key and username and it will make query in database,