session management- your opinion

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
User avatar
julian_lp
Forum Contributor
Posts: 121
Joined: Sun Jul 09, 2006 1:00 am
Location: la plata - argentina

session management- your opinion

Post by julian_lp »

What do you think about the following method to handle session data, and user login state?
Do you see any evident vulnerability in it?
How "secure" is it in your opinion?



Let's assume that the user data (user name, md5(pass), city, etc) is already saved in the Database...

1°) form with with login and password fields, as usual

a- test wheter there is no empty field

b-mysql_real_escapestring both user and pass


and then:

Code: Select all

if ($row->password_users == $a_pass){

			$id_sesion = md5(uniqid(rand(), true));

			$id_para_cookie = md5($id_sesion);			
			
			setcookie("UserSession", $id_para_cookie);
			$_SESSION['UserSession'] = $id_sesion;
			$_SESSION['Logued'] = true;	

			*$_SESSION[user_data'] = array (all the user data needed here.  )...



*This could be read from the DB to not making available that info on a shared server through session files

And when I want to see wheter the current user is logged in or not


Code: Select all

if ($_SESSION['Logued'] != true){
			return false;		  
		}
	
		$id_sesion = $_SESSION['UserSession'];
		$id_para_cookie = md5($_COOKIE['UserSession']);		
		
		///si el cookie no coincide con el numero de session almacenada en el server...
		if ($id_sesion != $id_para_cookie){
			return false;		  		  
		}
Last edited by julian_lp on Sun Nov 12, 2006 11:02 pm, edited 1 time in total.
User avatar
aaronhall
DevNet Resident
Posts: 1040
Joined: Tue Aug 13, 2002 5:10 pm
Location: Back in Phoenix, missing the microbrews
Contact:

Post by aaronhall »

Is this code working? The $_SESSION superglobal shouldn't be alive until you call session_start. Even if it does somehow, you may as well use php sessions as a simpler alternative to handling the session id and cookie validation yourself.
User avatar
julian_lp
Forum Contributor
Posts: 121
Joined: Sun Jul 09, 2006 1:00 am
Location: la plata - argentina

Post by julian_lp »

aaronhall wrote:Is this code working? The $_SESSION superglobal shouldn't be alive until you call session_start. Even if it does somehow, you may as well use php sessions as a simpler alternative to handling the session id and cookie validation yourself.

I just cut the original code. Of course I called session_start already...

I'm really trying to improve my UserLoginClass, to base any further project I do on it. I'm really afraid on session hijack, login attacks and so on...
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Post by Mordred »

This code should not be working.


Code: Select all

$id_sesion = $_SESSION['UserSession']; 
                $id_para_cookie = md5($_COOKIE['UserSession']);   
                
                ///si el cookie no coincide con el numero de session almacenada en el server... 
                if ($id_sesion != $id_para_cookie){ 
                        return false;            
                }
should be

Code: Select all

$id_sesion = md5($_SESSION['UserSession']); 
                $id_para_cookie = $_COOKIE['UserSession'];

Also, this:

Code: Select all

$id_sesion = md5(uniqid(rand(), true));
is not much different (i.e. better) than

Code: Select all

$id_sesion = uniqid(rand(), true);
(but it is not a "real" security issue, unless you're the NSA ;))

Another major issue is that having a session token md5()-ed would not stop an attacker from stealing the md5-ed token and using it, so there is no point in doing it. What you can do better is keep the IP of the logged user and a timestamp, so you can see if this is a session hijack by another ip, or a reuse of an expired session.

So,
1. Drop the md5 silliness, use the built-in sessionid support as aaronhall proposed
2. Keep IP and timestamp in the session, check for access from another IP and expirations. Renew timestamp on a valid access.
3. Destroy the current session before logging (see how they do it in session_destroy) to prevent session fixation attacks.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

Be careful not to double hash anything. Double hashing is less secure than a single hash.
User avatar
julian_lp
Forum Contributor
Posts: 121
Joined: Sun Jul 09, 2006 1:00 am
Location: la plata - argentina

Post by julian_lp »

Mordred wrote:This code should not be working.

should be

Code: Select all

$id_sesion = md5($_SESSION['UserSession']); 
                $id_para_cookie = $_COOKIE['UserSession'];
Absolutely correct. I dont know what I was thinking about...


Mordred wrote: Another major issue is that having a session token md5()-ed would not stop an attacker from stealing the md5-ed token and using it, so there is no point in doing it. What you can do better is keep the IP of the logged user and a timestamp, so you can see if this is a session hijack by another ip, or a reuse of an expired session.
But, Isn't it better sending a md5-ed cookie which doesnt reveal the server Session's id ?

I mean, the client would not be able to obtain the session Id
(I'm unsure wheter knowing the session Id is an advantage to the attaker or not though)

Mordred wrote: 2. Keep IP and timestamp in the session, check for access from another IP and expirations. Renew timestamp on
a valid access.
I've read that it is relatively common ISP's changing IP's. Taking into account that, I think it is discouraged to rely on Ip addresses. Valid users could be kicked off, which is one of the worst thing you can do ...
Mordred wrote:

3. Destroy the current session before logging (see how they do it in session_destroy) to prevent session fixation attacks.

I'll give it a read...


From what you've been writting, there is no much to do about secure session handling right?
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Post by Mordred »

But, Isn't it better sending a md5-ed cookie which doesnt reveal the server Session's id ?

I mean, the client would not be able to obtain the session Id
(I'm unsure wheter knowing the session Id is an advantage to the attaker or not though)
You are missing basic information on how sessions work. The client DOES know the session id (and it is not any of the variables you record into session and cookie) - it is a variable called (default) PHPSESSID and is automatically passed in a cookie or in the URL - there is no way of "hiding" or "encrypting" it, as then the session mechanism would simply not work.
I've read that it is relatively common ISP's changing IP's. Taking into account that, I think it is discouraged to rely on Ip addresses. Valid users could be kicked off, which is one of the worst thing you can do ...
No, we're talking here about checks in the limits of a session - that is between login and logout. An IP check is a must if you want to protect against session hijacking.
From what you've been writting, there is no much to do about secure session handling right?
On the contrary ;) Sessions can be secured to the extent that exploiting session vulnerabilities becomes no less easier than exploiting the server itself, which is the goal of PHP security after all.
feyd wrote:Be careful not to double hash anything. Double hashing is less secure than a single hash.
That is one thing, and it was part of my advice against it.

Another, no less dangerous thing from crypto point of view is "seeding" the md5 with data with weak entropy, as julian_lp was doing. Even if we assume that all bits of the uniqid are cryptographically random (which they aren't) thay still have less entropy than the resulting 128 bit md5.

Still, it is probably not much of a problem as cryptographic attacks against session id-s with enough random bits are hardly feasible in the near future, and I believe uniqid() fits the definition of "enough". I've seen much worse implementations though:

Code: Select all

md5(rand(10000));
Guessing a session id of this kind will take at most 10000/count(visitors) attempts which suddenly and painfully becomes quite feasible ;)

And that, julian_lp, is the point where that IP check will save the day ;)
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

An IP check isn't reliable either. The IP can vary wildly, legitimately for many users. If you use an IP check, be EXTREMELY careful in how you implement it. Too strict and you will kill any good experience certain users will have on the site. For example, all AOL users.
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Post by Mordred »

feyd wrote:An IP check isn't reliable either. The IP can vary wildly, legitimately for many users. If you use an IP check, be EXTREMELY careful in how you implement it. Too strict and you will kill any good experience certain users will have on the site. For example, all AOL users.
We seem do misunderstand each other.
By IP check I mean that after the user logs in, we keep his IP in the session, and later authorization checks must, among other things, verify that the current IP (which states it has a certain session id) is the same IP which opened the said session.
This reduces the possibility of session hijacking only to those with the same IP during the lifetime of the session.

I do not mean to implement authentication based on IP, just additional checking in the post-auth phase.

From usability point of view this would mean that getting disconnected while logged in may invalidate the session if the ISP decides to issue another IP to that client. Which means that the user will be logged out, or (maybe better) asked to reauthenticate with his password.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

Mordred wrote:
feyd wrote:An IP check isn't reliable either. The IP can vary wildly, legitimately for many users. If you use an IP check, be EXTREMELY careful in how you implement it. Too strict and you will kill any good experience certain users will have on the site. For example, all AOL users.
We seem do misunderstand each other.
By IP check I mean that after the user logs in, we keep his IP in the session, and later authorization checks must, among other things, verify that the current IP (which states it has a certain session id) is the same IP which opened the said session.
This reduces the possibility of session hijacking only to those with the same IP during the lifetime of the session.

I do not mean to implement authentication based on IP, just additional checking in the post-auth phase.

From usability point of view this would mean that getting disconnected while logged in may invalidate the session if the ISP decides to issue another IP to that client. Which means that the user will be logged out, or (maybe better) asked to reauthenticate with his password.
What feyd said still applies. A user's ip may legitimately change several times during their visit.
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Post by Mordred »

Jcart wrote:A user's ip may legitimately change several times during their visit.
This is new to me, explain please. Is that some mad practice of AOL or something?
This means that locking the session to the IP should be an optional setting rather than strict condition...
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

AOL users typically run through AOL's proxy servers. Their proxy servers are a giant farm of machines with wildly varying IPs. Every single request for every single component of the page could feasibly come from a different IP but end up on the same user's machine. This is true for other ISPs as well, AOL just happens to do it FAR more often.

Now consider DHCP. A Windows machine will renew the DHCP request when, if memory serves, 40% of the license time is remaining. Most DHCP servers will reissue the same IP to the user, however they aren't required to.

In conclusion, a user's IP address is not a reliable way to associate them.
User avatar
julian_lp
Forum Contributor
Posts: 121
Joined: Sun Jul 09, 2006 1:00 am
Location: la plata - argentina

Post by julian_lp »

Mordred wrote:
Jcart wrote:A user's ip may legitimately change several times during their visit.
This is new to me, explain please. Is that some mad practice of AOL or something?
This means that locking the session to the IP should be an optional setting rather than strict condition...
Exactly, that's what I was trying to tell you above. It's a mad practice, indeed. So, keep an eye opened on Ip address doesnt seem to be a good option...
Post Reply