Variable IPs: How variable are they? Best practices for tracking

Question

There are a lot of questions on StackOverflow relating to session security / session hijacking, but there doesn't seem to be a really good solution to the problem. The three most common suggestions are as follows:

1. Track the users IP address as part of their $_SESSION data, and possibly invalidate a session if it changes. The downside is that lots of users have dynamic IP addresses, so you risk invalidating a user seemingly at random (their perspective).

2. Same as 1., but using a User Agent. Two issues here: there may not be a UA to track, and they can change during browser upgrades, etc.

3. Second cookie, with a unique token. The problem here is that if an attacker gets a hold on the normal session cookie, they're very likely to be able to get a hold on your secondary token as well.

So, with these three options it seems that IP address is the best option, since you're guaranteed to be passed one and its independent of physical security (and if the user is physically compromised, you lose regardless). With that in mind, I have a couple questions relating to IP address changes:

1. How often would a users IP address really change under normal conditions. I have DSL at home, with the usual dynamic IP concerns, and according to gmail my IP hasn't changed in days. AFAIK, this only really happens when the modem cycles anyway, right? That seems like a rare enough event that it might be ok to invalidate the session.

2. I think I remember Jeff saying in one of the SO podcasts that they did something similar, though it was possibly for something else. The idea was that using the first two (I believe) octets of an IP address could be considered "close enough" in some circumstances. This allows a user to move around on the same ISP, but the system would notice if the user was suddenly in another ISPs range. Is this a viable tactic?

Answer 1

I'm not 100% sure that this belongs on webmasters, but I'll answer it anyway.

1. A users IP address only changes when their connection goes offline and comes back online. I have a dynamic IP at home, but I've had it for a month because that's how long it's been since I rebooted my router. Some ISPs force a disconnection every n days, some don't. It's impossible to tell, but in this day and age an IP address generally lasts for a few days. THAT SAID, they may have logged onto your website right before their IP changes (power outage, tripped over the network cable, etc) so it's not safe to assume this at all.

   The big issue you'll find here is if you're targeting mobile users. Then all bets are off if they're using their 3G or HSPDA networks to access your site.

2. The first two octets is probably pretty safe to use, but in Australia we have an ISP called BigPond who are (unfortunately) the largest in the country. Their IP addresses they allocate vary wildly, and there's no way you guarantee that their first two octets are going to be the same.

All of that said, I have never, ever, ever, ever been logged out of my Stack Exchange sites on my iPhone, home network, work laptop (even when I go to different sites or use HSPDA). So whatever they're doing works.

Also, I've never heard of using the user-agent as an authentication token. That could only be one part of the authentication process.

I think you'll find that having one or two session cookies is generally suffice, unless you're doing something so incredibly secure that you know there's going to be serious hijacking attempts against your site.

Answer 2

IP addresses can only change if the device that was issued the IP address has been disconnected and reconnected to the Internet. It will however depend heavily on your usage patterns and your ISP if and how often this occurs. Some ISP with dynamic IPs will nevertheless try to always issue you the same IP, while others (perhaps trying to get extra fees for static IPs) will issue you a new one even if you only drop off their network momentarily.

In my experience a change in IP address is a sufficiently infrequent occurrence to that it would not be overkill to invalidate a session over it. Note, however that unless your site is dealing with something sensitive this should still be avoided.

Take this site for example, what is the worst that could happen if someone hijacks my account? A little vandalism (that the community will quickly squash), maybe some lost reputation. The effects are minor to the user and the advantage little to the attacker. Therefore it would be overly aggressive to employ this measure here.

Conversely, my Google account could give an attacker access to all manner of private data (including -- as bonus -- access to this site). It is therefore natural for Google to be more cautious and (consequently) I frequently asked to confirm my identity there (although I'll admit that I have no idea what criteria they use).

Answer 3

1. My home IP address hasn't changed for several months. I know that with Shaw Communications (cable ISP in Canada) my IP address only changes when my external facing mac address changes (mac address of router or a computer directly connected to the modem) OR I don't use my internet for a few days.

   Not too long ago I was using a dial up connection and I noticed that my IP address changed every time i reconnected, although it didn't change all that much. I'm not sure if this would be simular for DSL and Wireless handsets.

   Another thing to consider would be session hijacking from the same local network. I'm not sure if there is really anything that can be done about that. Some schools and larger companies do have lots of computers on a single external IP. (some isp's too maybe? )

2. I'm not too sure I can answer if two octets are safe to use. I would be interested to see some data on a large userbase and how much their IP address's change.

Answer 4

• My DSL router disconnects, when I don't use it for 15 minutes, and I get a new IP each time.
• My provider uses two or three very different IP ranges.
• They force a disconnect every 24 hours (exactly like my previous two DSL providers did).

Answer 5

I don't think it is common on residential ISPs, but the proxy arrangement used for all outgoing HTTP(S) traffic by one of our major clients (a well known UK bank who for contractual reasons will need to remain nameless at this point) sometimes makes it look like their users switch IP address every few minutes, even sometimes in the middle of a block of requests for sub-objects (images, and so forth) on the same page, so using the exact IPv4 address as part of your session tracking is a bad idea in case some of your users are behind a similar arrangement.

In the case we have seen the addresses given out where within the same /24 range, and not the whole range, though to be extra safe I would recommend sticking to at most the first two octets of the IP address.

Even then you might inconvenience people if they use you app while travelling. For instance I sometimes have a webmail session open while travelling with my netbook - this can start on my home wireless, then move to the free wireless at the train station, then to my mobile phone provider if the train I end up on has no on-board wireless, then to another free wireless AP, then to what-ever network I use at my destination. All without ever logging out from Zimba (it is just there and working each time I unsleep the netbook and connect to what-ever is available) - I could flip between a couple of /16s on such a journey. Of course this is an edge case and may never affect enough of your users to make it worth considering in your plans - especially given all but the most picky users would be OK with needing to login again when they switch from home network to a mobile network.

Session hijacking is hard to block completely. If the hijacker can inspect the traffic between client and server than anything you send back and forth by over an unencrypted channel is easy to mimic and if the hijacker has managed to work from a host on the route between client and server they could even fake requests that appear to come from the right IP address so that wouldn't always help you. To stop session hijacking completely you need to use HTTPS (and if you want to feel really paranoid: if the attacker has some way of or gaining access to (or faking) your certificate HTTPS this does not stop MiTM session startup proxying based attacks). I suppose you could also implement something like DH key exchange to decide a shared key without transmitting it, and use that plus the current time plus some salt to make a hash that the server can veryify, but I very much doubt that would be practical (on a decent CPU with a modern JS engine as found in FF3.5+, Chrome, or similar you might be able to do the initial DH exchange for useful key sizes fast enough, but no mobile IE user will be able to get in inside a week).

One final problem with using the requester's IP address as part of your session tracking: if they are behind a NAT arrangement they could be sharing that IP address with hundreds of users. When connected to my 3G provider I get an address in the officially unrouted 10.x.x.x range - I don't know how many public facing addresses my requests could be seen to come from but it is possible that I share one public address with thousands of people at this point (I definitely won't have a public address to myself).

Long story short: the client's IP address isn't as good as you'd think for tracking sessions, though using the first two octets would offer some extra protection on top of what-ever other session tokens you use, without inconveniencing more than a few users.