Session Management

[Dunx]

OK, here's a technical question. I'm looking at writing some session management code, putting the session IDs into hidden fields on a form. Sessions will be initiated by a login, can be terminated by a logout, and can expire due to inactivity. As a security feature, I am intending to lock a particular session to the originating IP address.

Is this IP locking a good idea?

My concerns in more detail:

1. are originating IP addresses sufficiently fine-grained to make this a useful security measure?

2. how frequently do IP addresses change? Is there a risk that someone logging in from (say) AOL would be unable to maintain a session because their IP address would change between requests?

Any insight would be appreciated. Thanks.

[PaulKroll]

1. No. (See below :) )

2. Fairly frequently. Yes, although not common, it's entirely possible for a user to appear at two different IP addresses on consecutive requests (most often from ISP that use proxies, like AOL).

[Dunx]

Thanks. That's just what I needed to know (although not what I wanted to hear!)

[Rich]

Since session ids are guaranteed to be unique, there is no reason to worry about the IP address, which might not be unique for the entire session.

[kitchin]

I think what Rich means is you can use the ENV variable UNIQUE_ID to create a session id. On the next request, UNIQUE_ID will be different, but you are propagating the session id some other way. The ENV variable is here:

PHP: $UNIQUE_ID, or $_SERVER{'UNIQUE_ID'} if you're feeling persnickity
perl: $ENV{'UNIQUE_ID'}

Or... you can use PHP's built-in session management, which uses cookies, and failing that, url query strings.

[Rich]

I think what Rich means is you can use the ENV variable UNIQUE_ID to create a session id.
Essentially, yes. :)

There are a few different ways to obtain a session id. I wanted to make the point, though, that a session id is, by definition, guaranteed to be unique.

Of course, a session id without any data to go with it is rather useless. So you will need to store whatever data you want to maintain with that session along with the id. The IP address, then, just becomes another one of an infinite number of data that you may or may not want to store along with the other session data.

[hobbes]

I have typically used PHP session management. If the user does not have cookies enabled, I simply include the session id as part of the URL (GET) or via a hidden form field (POST).

[Dunx]

Oo - I didn't know about the UNIQUE_ID value. That's useful - thankyou. And so much quicker than the approach I was going to use to generate session IDs.

My thinking with associating the IP address with the session ID was as a security feature, rather than as a uniqueness constraint, the point being to prevent session hijacking by an eavesdropper. But then, since I do not anticipate running this stuff over a secure connection, nicking the passwords would be just as easy, so I don't know why I'm fretting.

Propagation: I'm intending to use hidden fields.

PHP: well, apart from being a Perl user, I'm writing this stuff for fun, so working from first principles is what is interesting to me. I've roughed out the session storage mechanism, and the expiration mechanism.

Thanks.

[Rich]

Dunx, since you mentioned you were using perl, you may want to check out the Apache::Session module.

[kitchin]

### %ENV is interesting to look at:
print "<pre>\n"; ## I like to see spaces
for $f(sort keys %ENV) {
($v= $ENV{$f})=~ tr/<>&`/[]**/; # you never know
# what might be in a query string or browser description
print "[ENV{$f} = $v]\n";
}