Re: Tying sessions to IP address - some real world data

[Andrew Sledge <asledge () gpc edu>]

As stated in the past, this is a problem with a lot of users with ISPs 
like AOL, BellSouth, SBC, etc.  Anyone with frequent disconnects or 
anyone that "sits" on a page may get a new IP once there is a 
reconnection or they start surfing again (in the case of broadband 
access - some broadband providers will 'time-out' their users if idle).  
One issue to consider is whether or not the fact that a user has to log 
in again and start a new session is really an issue:  what applications 
would this hinder?  As far as ecommerce scenarios go, they may have a 
shopping cart driven by a session - the likelyhood that a user will stop 
in the middle of shopping is not high in my opinion.  Even if they do, 
as long as their credit card or personal information is not sitting on 
the page there should be no problem on the users end - they may get a 
little irritated but thats about it.  They may have to refill thier 
shopping carts.  But I think as long as they are notified via an error 
message stating that thier message has timed out the user will 
understand.  What other applications may there be that would take so 
long that the user remains inactive long enough for their IP to time 
out?  Rarely does an IP time-out  in mid-surf.

sledge

Paul Johnston wrote:

> Hi,
>
> This issue has come up here several times. I thought I would use my
> personal website to harvest some data. I enabled Apache's mod_usertrack,
> default configuration which allocates a "browser window lifetime" cookie
> for every request that does not have a cookie. I update my logs to
> include this cookie, and also the X-Forwarded-For header.
>
> I plan to leave this running for a few weeks and write up the results
> properly. However, here's some early indications. They're just rough as
> I'm still working on the processing. Of 840 unique IP addresses, about
> 15 were observed changing IP address - and not just AOL users, various
> ISPs. Sometimes this appeared to be a user changing IP address - i.e.
> some pages are requested with one IP address. Then there's a gap. Then
> another (nearby) IP address requests some pages with the same cookie.
> But there are definite logged examples of load balanced proxies. When
> this happens, requests come from a whole bunch of IP addresses - usually
> 8 or so. They have always been in a 'close' range. Here's a couple of
> examples:
>
> Host 26.47.138.212.in-addr.arpa not found: 3(NXDOMAIN)
> cache1-2.ruh.isu.net.sa has address 212.138.47.11
> cache10-4.ruh.isu.net.sa has address 212.138.47.20
> cache13-4.ruh.isu.net.sa has address 212.138.47.21
> cache2-2.ruh.isu.net.sa has address 212.138.47.12
> cache3-2.ruh.isu.net.sa has address 212.138.47.13
> cache7-4.ruh.isu.net.sa has address 212.138.47.17
> cache9-4.ruh.isu.net.sa has address 212.138.47.29
>
> cache-dtc-aa06.proxy.aol.com has address 205.188.116.10
> cache-dtc-aa07.proxy.aol.com has address 205.188.116.11
> cache-dtc-aa08.proxy.aol.com has address 205.188.116.12
> cache-dtc-aa14.proxy.aol.com has address 205.188.116.18
> cache-dtc-ab01.proxy.aol.com has address 205.188.116.65
> cache-dtc-ac04.proxy.aol.com has address 205.188.116.133
> cache-dtc-ac05.proxy.aol.com has address 205.188.116.134
> cache-dtc-ad02.proxy.aol.com has address 205.188.116.196
> cache-dtc-ad11.proxy.aol.com has address 205.188.116.205
> cache-dtc-ad15.proxy.aol.com has address 205.188.116.209
> cache-dtc-ae10.proxy.aol.com has address 205.188.117.14
> cache-dtc-ae11.proxy.aol.com has address 205.188.117.15
> cache-dtc-ae19.proxy.aol.com has address 205.188.117.23
>
> Other results... about 15% of requests included an X-Forwarded-For
> header; many of these reveal private IP addresses. Something that has
> suprised me is a low proportion of clients appears to accept cookies -
> 460, just over 50%.
>
> So, what does this mean for tying sessions to IP addresses? Well, for a
> start it confirms that the practice will cause trouble, for about 2% of
> users. One suggestion was to tie the session not to the IP address, but
> to the class C network. The AOL results show that this is not sufficient
> - even looser coupling would be required. Another suggestion was to
> allow the user to re-authenticate with each IP address, adding them to
> the "allowed pool". With the AOL request coming from 13 different
> proxies, this will not work well.
>
> However, there may be a glimmer of hope... Some websites have an option
> at login time "restrict IP address - more secure" vs "don't restrict IP
> address - works with all ISPs". I would generally be against this,
> because I don't think most users are able to make the choice. However...
> the logs show that it would be possible to autodetect whether the user's
> IP will change, before they login. The real question of course is how
> reliable that would be. If it's 90% reliable, then that will reduce 2%
> of users having problems down to 0.2% - a much more acceptable figure.
>
> I'll be in touch again when I have more data.
>
> Paul