Session Identification Hashing - How to make it more Secure and Robust

Question

I wrote a PHP class which handles Session and store them in DB instead of normal Files in the server, you can find it on My Session Handler Class

In that post a user by name @AnotherGuy has raised some security concern/flaws about my Session Fingerprinting methods, which seems valid to me, and I am quoting him below :

Now to the last thing I will talk about. As said in the start I am no security expert, but I feel like your fingerprint solution is fishy. Imagine two different people from the same company using your site. The company uses a load balancer, which makes their IP address the same. If all company's browsers/clients are the same your fingerprint for these two people would be identical. Even though you are checking HTTP_X_FORWARDED_FOR headers you cannot rely on load balancers to send the header. I cannot tell you how to properly detect sessions using the fingerprint idea.

He was referring to the functions getFingerPrint() & _isSuspicious($fp)

    /**
    * [_getFingerPrint generates session fingerprints md5(USER AGENT + SECURE SESSION + IP ADDRESS)]
    * @return [strings] [encryted session info fingerprint]
    */
    private function _getFingerPrint()
    {
        return md5($this->_user_agent.self::SECURE_SESSION . $this->_ip_address);
    }

    /**
    * [_isSuspicious check for possible session hijack attempt, by comaparing encrypted user system specific values against exoisting records ]
    * @param  [string]  $fp [session fingerprint]
    * @return boolean
    */
    private function _isSuspicious($fp)
    {
        return ($fp != $this->_getFingerPrint()) ? True : False;
    }

I am using getFingerPrint() to generate a session hash using user agent + salt + ip address, and _isSuspicious() to check the fingerprint generated again against the fingerprint stored in Database.Well it seems to address security risk upto same extent, but when users are in Local Network(LAN etc) and also use same browser agents they seems to br viable to the security risk of session hijacking.

Also I am using the below function to get user's IP address,

/**
     * [_getRealIpAddr Get the IP address of the user]
     * @return [strings] [IP address of the client]
    */

    private function _getRealIpAddr()
    {
      if (!empty($_SERVER['HTTP_CLIENT_IP']))
      {
        /*check ip from share internet*/
        $ip     =   $_SERVER['HTTP_CLIENT_IP'];
      }
      elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))
      {
        /*to check ip is pass from proxy*/
        $ip     =   $_SERVER['HTTP_X_FORWARDED_FOR'];
      }
      else
      {
        $ip     =   $_SERVER['REMOTE_ADDR'];
      }

      return $ip;
    }

Now how can I make make this session hashing more robust when users share same network pool. The first solution comes to my mind is adding a COOKIE(random salt/number etc) to the hashing which will be particular to user specific system and in spite of having same User agent & ip address two users will have different Local Cookies. Anyone has any other better solution/options or completely different way to handle this situation ?

Edit 2 : What about using EVERCOOKIE [ but what if javascript is disabled ? ] !

@noize read the rules, one shouldn't -1 a question just because someone needs an answer and considers to be enlightened. If the OP wants to know more, I don't see anything wrong with it but only as elaborating the spheres of knowledge. -negging him is discouraging this flow itself and encouraging your personal preferences. +1. Give me a reason why it shouldn't be. — Shritam Bhowmick, Aug 12 '15 at 05:55
What is the "SECURE SESSION" variable that you're adding to the browser user agent and IP address? Sounds like that's the salt that you mention later, which should mean it's a randomly generated string. Is that per session or a global salt? In your last paragraph it sounds like that may be global because you mention the possibility of adding a 'cookie'. Normally user session IDs should always contain a sufficiently large random string that is mapped to their identity on the server. But it sounds like you don't have that yet? — PwdRsch, Aug 12 '15 at 18:08
@PwdRsch nope that is a class constant that's m using as a salt, please visit my link to the class. still I didn't implemented client machine specific salt. having doubts on that. — Dimag Kharab, Aug 12 '15 at 18:16
To take a step back, is this session ID the value you expect to be presented with by the user's browser (as a cookie) to authenticate who they are after login? As a general rule session IDs should be sufficiently random so they cannot be guessed and used to impersonate valid users. If you choose to store other info (the user's IP address and user agent) as part of that session then that's fine, but you're decreasing the security the ID offers if you fail to add the random element in as well. Is there a reason you are having doubts about adding in randomness? — PwdRsch, Aug 12 '15 at 18:53
See if thier is a session hijack attempt say someone steals session id. and Having the same network ip address (offce etc Lan etc) and coincidentally using the same browser / user agent , how to stop that? I am renewing my session id in 10 mins interval, but how I can make it much robust. How to uniquely identify client in a same network pool , when they share same ip nd same browser? — Dimag Kharab, Aug 12 '15 at 19:00
I'm not saying that you should abandon your goal of storing and checking the IP/user agent, but I am saying that the cookie should also store information that is randomly generated every time that session is generated or renewed. Otherwise you run into the problem you mention where two users with the same IP and browser can have the same session ID. With random info added that shouldn't be a problem. — PwdRsch, Aug 12 '15 at 19:13
@PwdRschNope nope I am not saying this, I am too thinking to store some random cookie — Dimag Kharab, Aug 13 '15 at 05:45

score 1 · Answer 1 · answered Aug 13 '15 at 23:01

A lot depends on what it is your trying to do and what the risks are associated with session hijacking. Generally, if you have a real need to ensure the session is actually owned by the right user, you would add additional checks, such as username and password etc.

The EFF has been doing a bit of work on how you can do browser fingerprinting to track people. It is possible that this work may provide you with some ideas/pointers on how you could increase your fingerprinting techniques.

See PanoptiClick

Thanks @TimX , I was talking in more genearal term , prelogin because after login we can have more added security layer — Dimag Kharab, Aug 14 '15 at 06:34

Session Identification Hashing - How to make it more Secure and Robust

1 Answers1