Session Management and Security

This is my current session management:

if(!isset($_SESSION["user"]["authenticated"]) || 
    !$_SESSION["user"]["authenticated"])
  redirect("login.php");

if($_SESSION["user"]["browserHash"] != md5($_SERVER["HTTP_USER_AGENT"]))
  redirect("logout.php?err=browser_mismatch");

if($_SESSION["user"]["IPHash"] != md5($_SERVER["REMOTE_ADDR"]))
  redirect("logout.php?err=ip_mismatch");

if(!isset($_SESSION["user"]["nonce"]) || 
  $_SESSION["user"]["nonce"] == $_COOKIE["SITE_nonce"])
{
  $nonce = md5(mt_rand() . time() . $_SERVER["REMOTE_ADDR"]);
  $_SESSION["user"]["nonce"] = $nonce;
  setcookie("SITE_nonce", $nonce, (60 * 15), "/path");
}
else
  redirect("logout.php?err=nonce_mismatch");

I am aware of changing IP issues an plan on using only the first 3 parts of the IP address. But what I am concerned about is the attacker is able to sniff headers and such. Then I won't be protected right? If I were an attacker within the victims network, I would simply make a quick GET request after I sniff one response header and I will get the regenerated nonce. Is there really a way to prevent this?

If it wouldn't be too much, I was also hoping on getting an insight on my approach. How can this be circumvented? Am I missing something big开发者_开发问答?

Your approach with recreating the nonce will fail if the user makes a new request after you, on the serverside, updated the nonce, but before the user receives the new cookie.

this happens for example if the user hit's F5 after a failed page load or if they open a lot of links in new windows/tabs.

Drop the idea for the IP-check. The IP address can change completely for many reasons. Think about load balancing proxies or mobile users switching roaming area for example.

A user-agent change could be detected and you could ask for a their password, but having them relogin (and restart what they where doing) is not very user friendly.

All in all, you are trying to protect your system from session stealing, with a session based on a cookie value. You need SSL for this, all other options will do little in terms of security. A cookie based session token is the currently accepted method for managing sessions, and deemed safe enough.

Also, CSRF attack are way more dangerous than session hijack attacks, and you do not stop those with what you propose. So my advice would be: focus on that area first.

To prevent sniffing of headers, you need to secure the connection over SSL/TLS.