Forum Moderators: coopster
I have been developing a cookie for managing return visits to a site after a user logs in and closes their browser. I have been encrpting the username of the user, using:
$username = $_SESSION'username'];
$encoded = base64_encode(serialize($username));
storing the $encoded value, then decoding it later when the user revisits the site with:
$login_cookie = $_COOKIE['cookie'];
unserialize(base64_decode($login_cookie));
...and testing to see if it exists.
Now this will fool most novices, but I am concerned that higher level hackers would break this. What is the best method of managing a user cookie, and what value should I store on their PC?
Eg: db table logged_user
CREATE TABLE logged_user (
cookie_id int(11) NOT NULL,
logged_user_data VARCHAR(255) NOT NULL,
PRIMARY KEY (cookie_id)
);
then when you get a new user logging in you create a database entry and send a cookie with the id alone.
setcookie('the_cookie_name', $cookie_id, $expire, etc....
When the user comes back you check the cookie_id if exists in the database and if so you retrieve the associated data from the database. You need to setup some algorithm to generate a unique key as the cookie id. Of course if the client end is hijacked an attacker will be able to do anything and none of this works.
If anyone knows a method like that, or knows how to use server side password encryption or decrypt the one way crypt method I would love to know.
Thanks.
1. Attacker visits commercial server obtains session cookie or session id via the url. Servers with shared SSL for instance do need the session to be passed via the url during transition from non-ssl to ssl and vice versa, to maintain integrity of the visitors info.
2. Deploys a jscript or link (depending how the session is exposed with a link is simpler but jscripts can cover all cases) to the client, via other sites or email, so once the target site is visited, the id that was obtained by the attacker is used. In other words visitor now uses an id known by the attacker.
3. Attacker can refresh the id for 2 main reasons a) so the session does not expire by accessing the targeted server, b) to monitor session access by others.
Another example is with the use of a common system where cookies aren't cleared for whatever reason or they are preset on purpose where the browser keeps sessions or other private data.
So now if the visitor say creates an account or logs in and the server doesn't regenerate a new session or if the visitor's browser is hijacked, the information becomes available to the attacker. That includes names, addresses etc.
So the attacker doesn't need to know how the session is encoded in this case, while he can employ such methods for popular commercial sites.
You will need the same key when you decrypt the data [php.net].
Note: you will still have to base64_encode and decode the encrypted COOKIE data value.