Page 1 of 1
session management- your opinion
Posted: Sun Nov 12, 2006 10:44 pm
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;
}
Posted: Sun Nov 12, 2006 10:50 pm
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.
Posted: Sun Nov 12, 2006 10:53 pm
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...
Posted: Mon Nov 13, 2006 9:53 am
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.
Posted: Mon Nov 13, 2006 2:44 pm
by feyd
Be careful not to double hash anything. Double hashing is less secure than a single hash.
Posted: Mon Nov 13, 2006 3:44 pm
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?
Posted: Tue Nov 14, 2006 4:34 am
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:
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

Posted: Tue Nov 14, 2006 8:25 am
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.
Posted: Tue Nov 14, 2006 8:46 am
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.
Posted: Tue Nov 14, 2006 11:58 am
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.
Posted: Tue Nov 14, 2006 2:52 pm
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...
Posted: Tue Nov 14, 2006 3:03 pm
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.
Posted: Tue Nov 14, 2006 4:04 pm
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...