Page 1 of 1

Session ID

Posted: Mon Nov 21, 2011 2:21 am
by Hermit TL
I've been working on some php code to authenticate a user while preforming certain actions while logged in. (I'm rather new to php) And I initially used a tutorial I found somewhere to get started on that. I've been using $_SESSION['id'] to store a string that is created by a simple authentication algorithm that changes on each login to verify a users' credentials. I finally got this working properly so the value does not change during the session but it does on each login. After looking into security a bit I was concerned about a malicious user being able to manually change the variables in $_SESSION as they pleased. This is when I learned the value stored in the cookie was not the same as $_SESSION['id'] and that session_id() is what returned the value in the cookie. After discovering this I noticed that the value did not change on each login (and I'm assuming that the value stored in the cookie is what an attacker would need to obtain to hijack the session) and then added regenerate_session_id() after each login which works perfectly for making sure the value in the cookie does not remain static on subsequent logins.

At the moment, I am happy with my current method of authentication; however, I'm wondering if using a value stored in $_SESSION['id'] generated by my own algorithm has any advantages/disadvantages over using the string generated and stored in the users' cookie.

For security reasons, I am not going to post the exact algorithm I am using but posted below is code very similar to what I am using to help illustrate what I have done.

after the users' username & password is authenticated a string is generated and stored in $_SESSION['id']

Code: Select all

$_SESSION['id'] = md5($results['password'] . $results['username'] . $results['password']). md5($results['last_login']);
links within the site include a string generated by and to be checked by my authentication function that is passed to the script in the URL and retrieved using $_GET(yes, it's filtered). This is my primary method for determining if a user is authorized to preform whatever action is being requested.
(Again, For security reasons, I am not going to post the exact algorithm I am using but posted below is code very similar to what I am using to help illustrate what I have done.)

Code: Select all

<?php

//*********************************

//*********************************

//*** authorize.php by Hermit TL

//*** 

//*** validate or generate

//*** authorization code

//*********************************

//*********************************



//START Required Header Code

session_start();

//END Required Header Code





//START authorize function

function authorize($authcode=NULL){

	switch($authcode){

		case NULL:

			$authcode = md5($_SESSION['id'] . md5($_SESSION['id'] . $_SESSION['id']));

			$result = $authcode;

		break;

		case !NULL:

			if ($authcode == md5($_SESSION['id'] . md5($_SESSION['id'] . $_SESSION['id']))){		

					$result = true;

			}else{

					$result = false;

			}

		break;

	}

return $result;

}

//END authorize function
?>
I know this is a security related question however I figured it was mostly related me not knowing what I was doing regarding session id's so that is why I posted it here.

Thanks in advanced to anyone (and everyone) for helping me out with my inexperience.

Re: Session ID

Posted: Mon Nov 21, 2011 6:33 am
by social_experiment
Hermit TL wrote:I'm wondering if using a value stored in $_SESSION['id'] generated by my own algorithm has any advantages/disadvantages over using the string generated and stored in the users' cookie.
The obvious advantage is that your algorithm is unknown; so if an attacker has your session id value (or can see it when you pass it along via URL), they cannot (easily) generate their own id values and attempt to fool your system.

Re: Session ID

Posted: Mon Nov 21, 2011 2:58 pm
by flying_circus
Hermit TL wrote:I'm wondering if using a value stored in $_SESSION['id'] generated by my own algorithm has any advantages/disadvantages over using the string generated and stored in the users' cookie.
In my opinion, there is no advantage to rolling your own session id generator.

However, I tend to send a token as a compliment to the session id for authorized sessions.

Re: Session ID

Posted: Mon Nov 21, 2011 4:45 pm
by Benjamin
Why not use the user id as $_SESSION['id']?

Re: Session ID

Posted: Mon Nov 21, 2011 5:28 pm
by Hermit TL
@Benjamin
Why not use the user id as $_SESSION['id']?
(Did you mean why did I want to have a random string of characters in $_SESSION['id'] rather than just using the login name provided by the user? The reason behind that was because I was concerned with session hijacking. (though I am unaware of how this is accomplished), I thought that simply having an easy to determine value placed in $_SESSION['id'] would allow another user to inject someone elses username in there and run around as that user in less than secure areas of the site. (I think I may have misunderstood your question, so I wrote this after the following was wrote.))

The reason behind that comes down to inexperience and following a tutorial and only sorta knowing what was going on when I was following it. (But I don't see any problem with that (other than maybe flowing against convention?) as long as I know what is where.)

I stored the user id, which I call username in $_SESSION['username'] and have a custom string generated to be stored in $_SESSION['id'], which I originally though was the same thing as session_id(). Initially I was using the primary key (auto incrementing INT) from the user account database for the $_SESSION['id'] until I realized how stupid that was. And I wrote the function that creates my custom session id before I even realized that I was using cookies (at first I thought the values from $_SESSION were stored somewhere client-side)

But after getting both my function and the value returned by session_id() to work, that is when I decided to ask people who know way more about it that I do.

I was thinking the same thing as social_experiment.
The obvious advantage is that your algorithm is unknown
Which surly sounds like a plus. However, I was more concerned with any major disadvantages and/or flaws.

@flying_circus
However, I tend to send a token as a compliment to the session id for authorized sessions.
Is this something you programmed into your scripts or is there something like session_id($token) that I missed?

Re: Session ID

Posted: Mon Nov 21, 2011 5:39 pm
by Benjamin
The variables in $_SESSION are not public.

The session can only be hijacked if the session_id is known. You can get this value from the constant SID.

You can regenerate it on every page request using session_regenerate_id();

Have a look here:
http://us2.php.net/manual/en/function.session-id.php
http://us2.php.net/manual/en/function.s ... ate-id.php

The problem with regenerating the SID on every request is that it will log users out of other tabs they may have open.

What are you trying to secure?

Re: Session ID

Posted: Mon Nov 21, 2011 5:57 pm
by Hermit TL
Thank you. I learned yesterday that variables in $_SESSION are not public, but that was after I had already programmed the function I posted above. Which is also when I learned about session_regenerate_id(), which I have already added to my login script. Thank you for the links; I will read them both after this post. And you're right about regenerating the SID on every request, I had that problem at first, but since have added the use of the users last login time to prevent the SID from changing until the user logs in again.

I'm trying to secure (as I write it rather than after the fact) a simple site that displays (and accepts) links (for a very particular type of portal) which is sure to attract people who are going to try to compromise the site. (No, it's not illegal. (No, it's not that either. :? ) But I'd rather not say what exactly it is until it's ready for alpha testing. (I'm paranoid like that.))

-Just 'cause you're paranoid, doesn't mean they're not out to get you! :lol: