Session ID
Posted: Mon Nov 21, 2011 2:21 am
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']
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.)
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.
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']);(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
?>Thanks in advanced to anyone (and everyone) for helping me out with my inexperience.