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

[Jim Manico <[e-mail]>]

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]> 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]> 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]> 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]> 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?
>