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

["Walter H." <[e-mail]>]

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