PHP Sessions + Useragent with salt

Scee picture Scee · Mar 5, 2009 · Viewed 9k times · Source

It keeps running in my mind the last couple of days, but I read some articles about how to make your PHP sessions more secure. Almost all of these articles say that you need to save the useragent in the session WITH an additional salt. Something like this:

$fingerprint = md5('SECRET-SALT'.$_SERVER['HTTP_USER_AGENT']);

The salt would make it harder for an attacker to hijack or whatever the session. But WHY add a salt every time you would check it like this:

md5('SECRET-SALT'.$_SERVER['HTTP_USER_AGENT']) == $_SESSION [ 'fingerprint' ]

So WHY would a salt make it more secure, since the attacker still only needs the useragent (which is relativly a small set of different useragents) and the sessionid?

Probably something small I'm overlooking, but can't figure it out, drives me crazy haha

Thanks!

Answer

Mez picture Mez · Mar 5, 2009

The reason that it's suggested to add a salt is simple. Generally, when you're creating this "fingerprint" - if you're using only one item of data, which has a limited dataset, then it makes it easier for an outside hacker to generate this, and hijack the session.

In your example above, yes, if the attacker has both the "fingerprint" and the User agent, then they will be able to hijack the session.

Adding a salt only makes it harder for an attacker to generate the fingerprint, it's a case of "if they have all but one piece of information, then the last piece of information is rendered useless)

I'd suggest that you add some more things in, for example, within vBulletin (a project I used to work on) the session ID hash (which is basically the same as the fingerprint) is generated with the following code.

define('SESSION_IDHASH', md5($_SERVER['HTTP_USER_AGENT'] . $this->fetch_substr_ip($registry->alt_ip))); // this should *never* change during a session

Also, a session hash is generated using

md5(uniqid(microtime(), true));

These are both checked when trying to identify the session

So, to hijack the session, the person would need to know the following

  • The time (exactly) on the server when the session was created
  • The users Browser agent string
  • The user's IP address

They would also have to spoof the IP address (or at least the first 2/3 octets) to be able to do this.

If they're actually at a point where they've managed to get the above information, then they're probably likely to be able to attack in other ways than just session hijacking.

vBulletin don't actually use a "salt" per se, but, in your above example, the salt is just adding a limited amount of entropy, it's always best to find as much entropy as possible.

For example, in something I'm currently writing in python, I generate a hash for usage with XSRF protection. The following is what I use.

    self.key = sha1(
        self.user.username +
        self.user.password +
        settings.SECRET_KEY +
        strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime())
    ).hexdigest()

Which takes the user's username and password, the current time, and a preset salt to generate this. This would be hard for an attacker to generate due to the salt, and the time (though, do note that this is only made secure by the fact that it changes once it's used, with time, it wouldn't take much for someone to crack this for a particular user if it wasnt changing)