Re: Tying a session to an IP address [summary]

[Paul Johnston <paul () westpoint ltd uk>]

Hi,

Thanks for the wealth of responses. The overall consensus is that in
general resticting sessions to an IP address will cause too many
end-user problems for widespread application. However, just logging an
IP address change may still be useful.

So an IP address can change because of load-balanced proxies, dial-up
users reconnenting and users reconfiguring proxies. I think a
reauthentication is acceptable in the latter two cases (indeed, I would
generally expect one). Looking at the AOL proxy page, my idea of just
checking the top 16-bits will not work. Someone suggesting looking at
the X_FORWARDED_FOR header - this is a bad idea as it makes address
spoofing trivial. In fact there was a recent vulnerabilitiy in phpBB
relating to this. In theory an option would be to have a list of address
known as trusted proxies and to trust the header from them - but I would
rather avoid this.

I am going to look at options for making IP address tracking a
user-configurable option (have seen one or two sites doing this). One
possibility may be to see if the IP address changes between requesting
the login page and submitting login details, or even bouncing the client
through a few client-side redirects to test if it changes.

For those interested, I don't have a specific application in mind. Some
of you may be aware of my JavaScript MD5 library
http://pajhome.org.uk/crypt/md5/ and I am looking at extending this to a
full authentication system. The point of the library is to let you do a
challenge-response login system, so the user's password is not
transmitted in the clear, even though you do not use SSL. This technique
is fairly widely used; for example Yahoo use my javascript to do this.
Clearly the javascript is downloaded over an insecure link, but my aim
is just to create a system which is secure against an attacker able to
eavesdrop and spoof packets, but unable to intercept packets between
client and server. This raises the bar somewhat, although it is clearly
unsuitible for high-security applications.

Regarding IP address spoofing - I'd generally say this is not trivial,
for TCP anyway. You need to guess a 32-bit ISN, which means 2^32 * 40
byte packets = 160 gigabytes of traffic - and you don't even know when
you guessed right. However, in the case of an eavesdropper they can
conviniently steal the ISN and theoretically spoofing is easier. Against
firewalled hosts their task is now easy, although for unfirewalled hosts
they will need to block the RST packets coming from the spoofed host.
Interesting - it's rare to hear of firewalls reducing security! Although
some ISPs do perform egress filtering, this is quite rare and attackers
will always be able to find ISPs that do not do this.

So ultimately this system is not eavesdropper protection, but it is
protection against the cookie being stolen due to XSS. And given that it
could be very valuable. Despite careful audit, XSS vulns are found all
over the place. But if you make your login screen never include user
supplied data and use IP address restriction, the impact of such
vulnerabilities is greatly reduced. Very good bang for buck security-wise.

Thanks again for all your thoughts.

Best wishes,

Paul

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul () westpoint ltd uk
web: www.westpoint.ltd.uk