Re: Linking a cookie to an IP address is a very bad in 2015...

["Eric Vyncke (evyncke)" <[e-mail]>]

On the Thalys, we usually change of country (hence also of mobile operator) every 45 minutes :-)

Else, mobile operators are heavily relying on NAT and some NAT are not RFC 6888 compatible (i.e. They keep changing your public IP address even if your phone RFC 1918 address stays the same).

In short, NEVER link a session cookie/state to an IP address ;-)

-éric

PS: and as a Belgian citizen, I hope that you have enjoyed Belgian beers/chocolate/people (albeit weather was awful probably) :-)

From: Jim Manico <[e-mail]<mailto:[e-mail]>>
Date: samedi 4 avril 2015 18:59
To: "Walter H." <[e-mail]<mailto:[e-mail]>>
Cc: Max Bruce <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Linking a cookie to an IP address is a very bad in 2015...
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-Date: samedi 4 avril 2015 18:59

I was just on the Thayls training around Europe. Wireless on the train was not usable so I used my phone data plan instead and watched IP addresses change every 45 min or so. It may happen rarely, but it happens.

It all depends on your user base.

And again, if you pin a user to the user agent, it will change during browser update and kick that user out early.

edge-cases? For sure but they are real...
--
Jim Manico
@Manicode
[phone]

On Apr 4, 2015, at 9:51 AM, Walter H. <[e-mail]<mailto:[e-mail]>> wrote:

user-agent: the change of user-agent should be noticeable after its restart;
when it changes without a restart you have a serious security problem,
e.g. some badware is setting "general.agent.override" in Firefox;

IP-address: with mobile devices you have to distinguish something;
as long as your device only changes the location in small distances, so that it stays inside the same mobile network operator,
the IP-address remains the same, because this is handled some layer below;

when the mobile network operator or just the ISP cuts the connection after a specified time, e.g. every 8 hours,
then this would be the same as a reboot of a normal computer and there it is not a good idea to be
able to go further inside the session, that was active before shutting down the computer ...
(think of an electronic banking session, which is a little bit more sensitive than just
looking around anywhere e.g. youtube)

think of what can happen, so that you bring the "login-page" instead of going further in the session;
I'd bring the login-page when one of the following changes:

source-ip:source-port
user-agent

but not, when you notice a change of the following:

screen resolution
client-time, except there is a defined timeout of e.g. 15 minutes


On 04.04.2015 18:12, Jim Manico wrote:
In the world of auto-updating browsers and therefor auto-updating user-agents, tying authentication to a user agent could have unintended negative consequences.

Tying authN to an IP address also has negative unintended consequences, like being on a mobile network while traveling, or being behind certain gateways - your IP address may change in short timespans.

On Apr 4, 2015, at 3:18 AM, Max Bruce <[e-mail]<mailto:[e-mail]>> wrote:

The session ID is a cookie, so in the headers. And yes, because it also checks that cookie, which is randomly generated. It just enforces a user-agent server-side. It DID enforce an IP, but I removed this for other reasons discussed earlier.

On Sat, Apr 4, 2015 at 2:49 AM, Walter H. <[e-mail]<mailto:[e-mail]>> wrote:
let me ask it different:  where is the Session ID, is it part of a http-header, part of a html-header, a session-cookie, or is it part of the URL itself that is requested?

the second: two ident configured hosts behind NAT do not differ neither in the user agent nor in the IP address; they only differ in the source TCP-port ...

On 03.04.2015 09:13, Max Bruce wrote:
When you say transmitting from host to server, what do you mean?
And yes, if I understand what your asking. It effectively compiled a random hash, and then enforced an IP & user agent. I have recently removed the IP enforecement though.

On Fri, Apr 3, 2015 at 12:10 AM, Walter H. <[e-mail]<mailto:[e-mail]>> wrote:
On 01.04.2015 21:48, Max Bruce wrote:
What about linking to several? I wrote a session system for my Web Server that will only allow access to the original Session ID if the IP & User-Agent has remained unchanged, in order to protect against session hijacking. I've found it's highly effective, unless you IP Spoof.
what kind of mechanism do you use for transmitting the Session ID from host to server?
does it prevent access from an ident configured but different host behind a NAT?