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

I think using the IP address for these purposes is fantastic - in intranet environments where IP per user is static. :)

--
Jim Manico
@Manicode
(808) 652-3805

> On Apr 1, 2015, at 8:07 AM, Willy Tarreau <w@1wt.eu> wrote:
> 
> Hi Michael,
> 
>> On Wed, Apr 01, 2015 at 10:52:32AM -0400, Michael Sweet wrote:
>> Um, no.  IP addresses, by themselves, have never been useful as unique client
>> identifiers.  NAT, DHCP, proxies, roaming, etc. all contribute to their
>> instability.
> 
> OK for this indeed.
> 
>> Typically the client address will be incorporated into the session cookie
>> value which contains a hash of a timestamp, client address, client-supplied
>> headers (like User-Agent), server-supplied nonce value, and user ID and
>> password (for sites with user accounts).
> 
> Taking the user-agent would probably be more reliable than the IP address.
> 
>> The main reason for incorporating client values into the session cookie hash
>> is to (imperfectly) tie the cookie to the identity of the client (vs. the
>> user) and (imperfectly) protect against replay attacks, particularly for HTTP
>> connections.
>> 
>> From an operational standpoint, I've used this method on dozens of web sites
>> over the years and maybe had 10 reports of problems due to NAT/proxies, over
>> millions of visitors.  There may be some "selection bias" in that number (all
>> of my web sites have been tech-oriented) but I don't think this is something
>> that affects a large number of users given its continued, widespread use.
> 
> Well, I've been used to see in average about 5% of users whose IP address will
> change during a session on some large web sites. This is fairly common for
> sites that people access from their work, and it's getting more common with
> smartphones automatically picking a wifi access when they find one, which
> is able to change after a few seconds/minutes of idle.
> 
>> (Note: I'm not claiming that this practice is perfect or that we shouldn't
>> try to come up with something better...)
> 
> Anyway when cookies are stolen, the attacker is inside the browser. In banking
> environments, the fraudulent operations are performed entirely from within the
> browser so this sort of protection is totally useless since the cookie doesn't
> need to be reused outside of this browser.
> 
> Regards,
> Willy
> 
>

Received on Wednesday, 1 April 2015 15:14:37 UTC