Prevent session cookie hijacking WITHOUT SSL

To prevent session hijacking, i tried to assign a specific cookie name to each user based on these variables: User-agent and IP Address.

I have used following function to generate session cookie name which holds session ID.

static function getSessionName(){
    $id= @md5(base64_encode(self::$secretToken.$_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"]));
    while(is_numeric($id{0})){
        $id = substr($id, 1).$id{0};
    }
    return $id;
}

It means that every user which visits my website, will have a different session cookie name. It will block hijacker from using cookies of somebody else, unless he/she changes his/her user agent to victim's user-agent; and tries to appear online using victim's IP address somehow, like using user's internet modem, router, NAT, etc.

Let me explain it using a example. So, if two users use same browser and connect from same IP address, they get same cookie names (assume f5e30acc605e938b097dee73c0272470).

Now, the script will look for session ID inside a cookie named f5e30acc605e938b097dee73c0272470 on these two clients. In this condition, one of the clients can hijack other's cookie. Same IP, same User-Agent and then same cookie name!

This method is good but not quite secure. Changing user-agent is not so difficult to do, and victim and hijacker may have equal IP addresses if they connect from public networks like Coffenets, Public hotspots, etc.

~~It's important to deny the attacker from doing so, especially if we use a "Remember Me?" option to generate long-lasting session cookies.~~

Does anybody have a suggestion about this problem?

As i researched, one of the solutions was using SSL and secure cookies. But, i'm looking for a solution without SSL usage.

If you are basing your senario on the assumption that

1) The attacker can have the same ip address and 2) The attacker can pretend to have the same user agent as they have access to any information transmitted over the net

Then there is no possible way for you to verify the identity of this cookie. This is because you have assumed in your assumptions that all this information is available.

You have two solutions: a) use SSL b) Trust that your users won't be in the same coffee shop as an attacker, that the IP address is valid, and that your site is not yet important enough to deserve a large scale attack. What can they do yet - make offensive posts and spam? They could do that anyway with their own accounts.

From my experience and from what I have read, I agree with the statement that "premature optimization is [one of the greatest evils of programming]". Focus your time on building a site that works and is useful for people and then, if something start to go wrong, think about getting an SSL certificate. You just don't have the money for the certificate and you don't have the money because your site has not yet been successful (so do that first).

"Premature Optimization" and paranoid security measures are temptations for programmers because we like to think of ourselves as working on large-scale, very important projects when we are not [yet].