User Auth - is this secure?

[BenSeb]

Hi

To authenticate my users within a control panel, i check their pass/username and if matches, set a sesson variable $SESSION["authentid"] which stores the record the user may access. When pages are accessed, 'entid' is passed to show the correct record, and i check this against the authentid to see if they are allowed to access. I also set $SESSION["auth"] = 1.

as i have an admin user who can access all records, if $SESSION["promotoradmin"] is set i automatically authenticate

is the code below 'hackproof'?

session_start();
// CHECK USER IS AUTHENTICATED
$ientid = $_REQUEST["entid"];
$ientid = myescape_string($ientid);
$allowed = $_SESSION["authentid"];
$proceed = 0;
   if ($allowed == $ientid){ $proceed = 1;}
if ($_SESSION["promotoradmin"] == 1){$proceed = 1;}
if ($proceed == 0 || $_SESSION["auth"] != 1) {header("Location: promotorlogon.php"); exit;}
// USER IS AUTHENTICATED

[adamgeorge]

Dude, nothing is "hack proof". If someone really wants to breach your site, then there is always some way to do it.

... that's just they way it is.

Still, good site security will discourage most intruders.

Anyway, I looked at your code, and I don't really follow what it's doing lol.

Like I don't know... what's entid? the page identifier? If so, what does that have to do with $_SESSION["authentid"] ?

anyway... not really a good idea to just check session variables... I mean... what's a session? just a glorified cookie isn't it? lol. so... people can muck around with your cookies you know. Should always check against a database which stores the user names and passwords to properly authenticate somebody.

Hope that helps. I'm no expert on security though by any means.

cya
-Adam 🙂

[BenSeb]

Basically, EntID is like a userid. It identifies the users

The users login, and the scripts check details against the database. If they are correct, their EntID is stored in AuthEntID

They then reach a control panel. when they go to different pages, such as test.php?entid=4 the script above checks that they are allowed to access the record for entid 4 (because 4 should be in their 'authentid' session cookie.

i have done it that way because when admin logs in, they need to specify which record they want to look at using ?entid=

sound good?

[adamgeorge]

yeah, that's ok, but I would add to that. I use a similar idea on my website.

What I do is I store the user id, the administration level id, password, and the date they logged in a cookie.

now, the password is md5 encryped so nobody can read it.

on top of this I use just one cookie to store everything and encode all the data using base64_encode() for extra security.

<?
$cookieData = base64_encode("$iMemberID;$sMemberNameName;$sMemberPassword;$dtMemberLastLogin");
return setcookie("cSession", $cookieData, time()+$iSessionLength);
?>

It's not unbreakable, but nobody is going to be able to read any of that data in a hurry and certainly not the password.

now, when I need to authenticate somebody for a page, I just check the cookie like so:

<?
if(isset($_COOKIE["cSession"])){
$this->cSession = $_COOKIE["cSession"];
$cSession = base64_decode($this->cSession);
$cSession = explode(";", $this->cSession);
$sIDValue = $this->cSession[0];
$sNameValue = $this->cSession[1];
$sPasswordValue = $this->cSession[2];
$sDateLastLoginValue = $this->cSession[3];
}
?>

and then check the username and password variables against the database.

So, I got this idea from reading some of the source code to phpNuke portal system. I thought it was a good idea an applied the concept to my website. I prefer cookies to using sessions, I've never used sessions on anything. Pretty much a session is a cookie, but you don't have as much flexability... so.. you may as well just use a cookie. It's not anymore code, really...

well, hope that helps
-Adam 🙂

[adamgeorge]

whoops, I mucked up some of that code.

I modified from what I have on my website, cause I like to do most things object oriented, and it wouldn't have made sense to show it here in that context.

here it is:

<?
if(isset($_COOKIE["cSession"])){
$cSession = $_COOKIE["cSession"];
$cSession = base64_decode($cSession);
$cSession = explode(";", $cSession);
$sIDValue = $cSession[0];
$sNameValue = $cSession[1];
$sPasswordValue = $cSession[2];
$sDateLastLoginValue = $cSession[3];
}
?>

[BenSeb]

looks like a good plan. why do you need to store the password at all though? do you ask them to reconfirm it at certain times?

i know md5 is ideally 'secure' but why store it at all?

[adamgeorge]

Well, you store the password so you can authenticate on any page without asking for the password again.

It's stored in the cookie, so you just grab it out and query it against the database to authenticate them.

Just checking to see if the cookie is there is not really secure enough. I use the cookie to store the current users main account details, then can conveniently use them whenever I need to check to see if they're a valid user or whathaveyou.

cya man,
-Adam 🙂

[mcgruff]

Cookies can be sniffed or stripped off your PC via cross-site scripting attacks so I'm not sure if adamgeorge's solution is adequate - depends on what level of security you need really.

A better solution might be to do an IP check and store only the hashed pass in the cookie (I wouldn't be happy about putting access level in the cookie: suppose I register as an ordinary user for a forum, then edit my cookie to an admin access level..).

When a user logs in, store the login IP in the users table.

In the authorisation check at each page load, check the cookie pass against the database to get the authorisation level. From the same query, check for a match with $_SERVER['REMOTE_ADDR'] and the login IP stored in the user row. A stolen cookie on a different computer (and a different IP) can hence be blocked.

Making the cookie time limited is also useful - helps to protect against hotseating or shared IPs on NAT networks. That does mean, however, that you can't automatically log users in.

[adamgeorge]

Yeah, I don't actually use the adminlevel access in the cookie for security checks. I just put it in there for quick reference... like... all authentication is always done against the database. But it may be usefull to have the adminlevel sitting in the cookie in case you need it for something in which security is not an issue. Same reason I put dtLastLogin in there too.

But anyway, matching the IP's during a session is an interesting idea. I think I'll try that out...

cya man.

[bsmith]

I have read that some ISP's, mainly AOL, will actually rotate IP addresses for a single user during a dialup session, so if any of your users are AOL users, it may break the ip-based auth.

Just a little extra info, I have had this problem with commercial software, not something I wrote.

B