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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 1 Apr 2015 11:32:05 +0000

In the era of scarce IPv4 addresses, servers should NOT link the HTTP session cookies to the user-agent IP address...

I have posted in the IETF V6OPS WG the following:
http://www.ietf.org/proceedings/92/slides/slides-92-v6ops-6.pdf
https://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie

In short, heavy use of NAT and/or dual-stack (IPv4/IPv6) can cause a change of user-agent address => lost of session.

Any suggestion on how this can be addressed? I know at least two major web sites in Belgium that removed IPv6 from their web site due to this issue (and their security department not wanting to unlink IP address from the session cookies)

Comments are welcome

-éric

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 13:46:08 +0200

On Wed, Apr 01, 2015 at 11:32:05AM +0000, Eric Vyncke (evyncke) wrote:
> In short, heavy use of NAT and/or dual-stack (IPv4/IPv6) can cause a change
> of user-agent address => lost of session.
> 
> Any suggestion on how this can be addressed? I know at least two major web
> sites in Belgium that removed IPv6 from their web site due to this issue (and
> their security department not wanting to unlink IP address from the session
> cookies)

I'm amazed people still do that in 2015, I had the idea to do it in 1999
until I realized it was stupid and never did it! So I'd have guessed that
16 years later everyone would have also figured this! If IP addresses
were stable during a session, cookies would not be needed, the address
would be used instead. So it's precisely because addresses are unreliable
that cookies exist.

Too bad people don't learn from others' mistakes...

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 13:58:39 +0200

On Wed, Apr 01, 2015 at 11:52:04AM +0000, Eric Vyncke (evyncke) wrote:
> Indeed, people never learn...
> 
> OTOH, linking a session cookie to the user-agent IP address renders
> 'session cookie stealing' much more difficult

Yes, and accessibility as well. While I definitely understand the
principle of considering a source address to help with the triage
of requests when dealing with a massive attack, in which case it
will definitely get rid of a few valid users, it's absurd to do it
by default.

Regards,
Willy

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 1 Apr 2015 11:52:04 +0000

-éric

On 1/04/15 13:46, "Willy Tarreau" <[email-masked]> wrote:

>> In the era of scarce IPv4 addresses, servers should NOT link the HTTP
>>session
>> cookies to the user-agent IP address...
>>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 01 Apr 2015 10:52:32 -0400

Willy,

> On Apr 1, 2015, at 7:46 AM, Willy Tarreau <[email-masked]> 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.

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).

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.

(Note: I'm not claiming that this practice is perfect or that we shouldn't try to come up with something better...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 17:07:16 +0200

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.

> 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

---

From: Jim Manico <[email-masked]>
Date: Wed, 1 Apr 2015 08:14:06 -0700

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 <[email-masked]> wrote:
> 
> Hi Michael,
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 17:16:34 +0200

On Wed, Apr 01, 2015 at 08:14:06AM -0700, Jim Manico wrote:
> I think using the IP address for these purposes is fantastic - in intranet
> environments where IP per user is static. :)

That was my initial goal in 1999 until I realized that some clients were
using DHCP and that it would not even work outside due to the so called
"AOL effect" by then.

Willy

---

From: Max Bruce <[email-masked]>
Date: Wed, 1 Apr 2015 12:48:36 -0700

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.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 21:54:39 +0200

> hijacking. I've found it's highly effective, unless you IP Spoof.

Sure it's highly effective. Just like it's highly effective in randomly
denying access to people who browse using multiple WiFi access point or
who switch between 3G and WiFi.

Willy

---

From: Max Bruce <[email-masked]>
Date: Wed, 1 Apr 2015 12:57:56 -0700

That's a great point. What about User-Agent checking?

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 22:09:35 +0200

> That's a great point. What about User-Agent checking?

Yes, that's what Michael mentionned as well. I *believe* that some
UAs send different values when a plugin performs a request, but I'm
not 100% certain. That's clearly something to check for those who
want to do this though.

I find it fun to see people scared about cookie stealing at an era
where some others are pushing hard for TLS everywhere. Either one
is a problem of the past, or the other is ineffective against info
leak :-)

Willy

---

From: Michael Sweet <[email-masked]>
Date: Wed, 01 Apr 2015 16:13:57 -0400

Here is the information our security guys rely on for best practices in web site session cookies:

    https://www.owasp.org/index.php/Session_Management_Cheat_Sheet <https://www.owasp.org/index.php/Session_Management_Cheat_Sheet>

Client IP address is currently listed as one of the properties that can be used to bind the session ID to a specific client.

I'm not sure whether current PHP, etc. use the client IP or User Agent to validate the session ID...

> On Apr 1, 2015, at 7:32 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> http://www.ietf.org/proceedings/92/slides/slides-92-v6ops-6.pdf <http://www.ietf.org/proceedings/92/slides/slides-92-v6ops-6.pdf> 
> https://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie <https://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie> 
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 01 Apr 2015 16:30:15 -0400

Willy,

> On Apr 1, 2015, at 4:09 PM, Willy Tarreau <[email-masked]> wrote:
> 

MiTM attacks/proxies can cause cookies "protected" by TLS to be exposed, but at that point the client IP validation is probably also defeated.  Javascript-based attacks are also possible, assuming you haven't set HttpOnly on the session cookie, but again those will come from the same IP so the validation is ineffective.

Probably the "right" answer is to always use TLS, never use the client IP or other request headers when constructing or validating the session ID, limit the amount of time a session ID is valid, and make sure your session IDs cannot be easily guessed.  (Which is pretty much what the OWASP cheat sheet says, minus the IP validation stuff...)

---

From: Jim Manico <[email-masked]>
Date: Wed, 1 Apr 2015 14:44:49 -0700

Michael,

I manage the cheatsheet series for OWASP. If you think this should be changed hit me up off list at [email-masked]

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

> On Apr 1, 2015, at 1:13 PM, Michael Sweet <[email-masked]> wrote:
> 
>     https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 2 Apr 2015 06:18:49 +0000

Using User-Agent appears to me as more stable than the IP address for sure :-)

And to reply to the suggestion of always using SSL (which is probably good anyway): it is not enough as cookies can be stolen from the browser itself if an attacker can inject some javascript into the browser (using the good old cross site scripting for example)

-éric

From: Max Bruce <[email-masked]<mailto:[email-masked]>>
Date: mercredi 1 avril 2015 15:57
To: Willy Tarreau <[email-masked]<mailto:[email-masked]>>
Cc: Jim Manico <[email-masked]<mailto:[email-masked]>>, Michael Sweet <[email-masked]<mailto:[email-masked]>>, Eric Vyncke <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Linking a cookie to an IP address is a very bad in 2015...

On Wed, Apr 1, 2015 at 12:54 PM, Willy Tarreau <[email-masked]<mailto:[email-masked]>> wrote:

Willy

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 2 Apr 2015 06:34:04 +0000

Jim

Thanks for offering to update the OWASP cheat sheet in the sections:

  *   "Session ID Content" (where it should be stated that the stored client IP address cannot be used for authentication check),
  *   "Session ID guessing" (where it should be stated that blocking on IP address can actually block hundreds of valid users when this address is shared by hundreds of ISP subscribers)
  *   but the major change is in "binding the session ID to other user properties" where clearly the session ID cannot be linked anymore to the client IP address

There is also another thing to change in this cheat sheet in section "Logging Sessions Life Cycle": logging the IP address has little meaning nowadays (heavy NAT in use), see RFC 6302 which recommends logging the remote/client TCP port as well.

I am more than happy to assist you in rewriting those sections

-éric

From: Jim Manico <[email-masked]<mailto:[email-masked]>>
Date: mercredi 1 avril 2015 17:44
To: Michael Sweet <[email-masked]<mailto:[email-masked]>>
Cc: Eric Vyncke <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Linking a cookie to an IP address is a very bad in 2015...

Michael,

I manage the cheatsheet series for OWASP. If you think this should be changed hit me up off list at [email-masked]<mailto:[email-masked]>

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

On Apr 1, 2015, at 1:13 PM, Michael Sweet <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 1, 2015, at 7:32 AM, Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:

Comments are welcome

-éric

---

From: Michael Sweet <[email-masked]>
Date: Thu, 02 Apr 2015 06:46:17 -0400

The cookie info should not be accessible to JavaScript if the HttpOnly flag is specified when the cookie is set... (Unless the browser is seriously broken...)

Sent from my iPad

> On Apr 2, 2015, at 2:18 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> From: Max Bruce <[email-masked]>
> To: Willy Tarreau <[email-masked]>
> Cc: Jim Manico <[email-masked]>, Michael Sweet <[email-masked]>, Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Zhong Yu <[email-masked]>
Date: Thu, 2 Apr 2015 11:11:19 -0500

A TLS session is a pretty good alternative. Within one browser
session, different HTTPS connections to the same server will likely
share the same TLS session. The server can bind state to the TLS
session; there's no need for an HTTP cookie, if the site is HTTPS
only.

Zhong Yu
bayou.io

On Wed, Apr 1, 2015 at 6:32 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> session cookies to the user-agent IP address...
>
> sites in Belgium that removed IPv6 from their web site due to this issue
> (and their security department not wanting to unlink IP address from the
> session cookies)
>
> Comments are welcome
>
> -éric
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Apr 2015 09:19:35 -0700

On 2 April 2015 at 09:11, Zhong Yu <[email-masked]> wrote:
> The server can bind state to the TLS

I always recommend against that.  Connections break.

---

From: Zhong Yu <[email-masked]>
Date: Thu, 2 Apr 2015 11:18:30 -0500

The HttpOnly flag is ... interesting. If a page contains injected
scripts, game over, the attacker can do anything as the authorized
user. The HttpOnly flag is like, you are walking in a thunderstorm?
here, wear this tinfoil hat.

Zhong Yu
bayou.io

On Thu, Apr 2, 2015 at 5:46 AM, Michael Sweet <[email-masked]> wrote:
> The cookie info should not be accessible to JavaScript if the HttpOnly flag
> is specified when the cookie is set... (Unless the browser is seriously
> broken...)
>
> Sent from my iPad
>
> And to reply to the suggestion of always using SSL (which is probably good
> anyway): it is not enough as cookies can be stolen from the browser itself
> if an attacker can inject some javascript into the browser (using the good
> old cross site scripting for example)
>
> -éric
>
> Cc: Jim Manico <[email-masked]>, Michael Sweet <[email-masked]>, Eric
> Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Zhong Yu <[email-masked]>
Date: Thu, 2 Apr 2015 11:39:54 -0500

> I always recommend against that.  Connections break.

The new connection will like reuse the same TLS session[1]. The
browser is not required to do that, but from my tests,
firefox/IE/chrome on Windows apparently do.

Zhong Yu

[1] http://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Apr 2015 09:47:33 -0700

> firefox/IE/chrome on Windows apparently do.

Only if you hit the same server in the cluster, or the cluster has
shared resumption AND session state.  HTTP is a message-based
protocol, binding state to a connection has to be regarded as an
optimization only.

---

From: Zhong Yu <[email-masked]>
Date: Thu, 2 Apr 2015 11:51:08 -0500

On Thu, Apr 2, 2015 at 11:47 AM, Martin Thomson
<[email-masked]> wrote:
> shared resumption AND session state.

But a session-id cookie will have the same problems.

We could embed all session data in a fat cookie, but I don't think
that's a common practice.

> HTTP is a message-based

---

From: Michael Sweet <[email-masked]>
Date: Thu, 02 Apr 2015 12:59:48 -0400

HTTPS does not guarantee that the connection stays up forever or that there is only one connection, particularly for HTTP/1.1 but even for HTTP/2 it isn't a "safe" assumption.

> On Apr 2, 2015, at 12:11 PM, Zhong Yu <[email-masked]> wrote:
>

---

From: Jim Manico <[email-masked]>
Date: Thu, 2 Apr 2015 10:07:52 -0700

It effectively stops JS from reading a cookie. All browsers support it well today. Use is, it does no harm.

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

> On Apr 2, 2015, at 9:18 AM, Zhong Yu <[email-masked]> wrote:
>

---

From: Jim Manico <[email-masked]>
Date: Thu, 2 Apr 2015 10:09:19 -0700

Embedding session data in a fat cookie is actually •very• common in stateless REST architectures. Encrypt and sign those cookies as well.

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

> On Apr 2, 2015, at 9:51 AM, Zhong Yu <[email-masked]> wrote:
>

---

From: "Walter H." <[email-masked]>
Date: Thu, 02 Apr 2015 21:08:07 +0200

On 01.04.2015 13:46, Willy Tarreau wrote:
> until I realized it was stupid and never did it!
it is not stupid, it is very clever ..., why see below
>   So I'd have guessed that
> would be used instead.
the WAN address, that everybody inside the LAN has in common?

think of the following:
in my country there existed a bank, that had in its electronic banking 
no session cookies;
they had a worse solution,
the session was stored in the URL, so it was possible not only on 
another browser or session of the same computer to use this URL
also on another computer, because, the WAN address was the same  ...

and now think of MITM, nothing easier than this, you use the same session;
can you really proof, money is lost, and it was not you?

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 2 Apr 2015 21:32:43 +0200

> also on another computer, because, the WAN address was the same  ...

You will never get rid of developers who do crap until they are
responsible for the impact of their ignorance or lack of care.

> can you really proof, money is lost, and it was not you?

At least in my country, it's the bank who needs to prove it was me. That
makes a huge difference because they go to great length analysing fraud
and take security with seriousness.

Willy

---

From: "Walter H." <[email-masked]>
Date: Fri, 03 Apr 2015 08:33:52 +0200

On 03.04.2015 08:21, Willy Tarreau wrote:
> On Fri, Apr 03, 2015 at 08:14:02AM +0200, Walter H. wrote:
>> have you ever looked at your cards (credit, debit, ...) a little bit
>> more precise?
>> they have both the magnetic part on back and the chip on front ...
> Yes and you can even erase it (and lose access to parkings and tolls).
>
yes, and you also can make a 1:1 copy on another "duplicate" card ...
guess why you lose access?
>>> The magnetic part contains the same things that are printed on the card.
>> wrong information; the magnetic part has the ident function as the chip
>> ...
> Nothing related to the pin. You *cannot* use your PIN offline with the
> magnetic stripe.
wrong, outside the EU the only way ...
>> guess why you must enable your card for areas outside EU?
>> (this rule is since Jan, 1st 2015)
> So that your bank accepts transactions from outside the SEPA area.
>
and how does this payment really work?
> Anyway I'm not interested in pursuing this useless conversation, I'm
> wasting my time trying to convince you you're mistaken and that's not
> my problem.
I'd say, I should tell this somewhere,
  to sort you out from IETF workgroup, because your wrong knowledge is a 
risk to the whole internet

get the right information, to be able to talk about ...

have a nice day

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 3 Apr 2015 08:41:22 +0200

> get the right information, to be able to talk about ...

Walter, as I told you in last private e-mail, I'm not interested at all
in pursuing this conversation with you, and that's not by trying to put
it back on the ML that you'll revive it. It's off-topic. Period. Thanks
for stopping this pollution now.

> have a nice day

Same to you.

Willy

---

From: "Walter H." <[email-masked]>
Date: Fri, 03 Apr 2015 09:10:56 +0200

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?

---

From: Max Bruce <[email-masked]>
Date: Fri, 3 Apr 2015 00:13:22 -0700

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. <[email-masked]>
wrote:

> does it prevent access from an ident configured but different host behind
> a NAT?
>

---

From: "Walter H." <[email-masked]>
Date: Sat, 04 Apr 2015 11:49:25 +0200

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:
> 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. <[email-masked] 
> <mailto:[email-masked]>> 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?

---

From: Max Bruce <[email-masked]>
Date: Sat, 4 Apr 2015 03:18:37 -0700

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. <[email-masked]>
wrote:

> 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 ...
>
> random hash, and then enforced an IP & user agent. I have recently removed
> the IP enforecement though.
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 4 Apr 2015 10:26:09 +0000

Walter,

The session-ID can be in a session cookie (preferred) but also in the URL (which is of course not really secure).

Two hosts behind a NAT _may_ share the same IP address (usually there is a pool of IP addresses) and the TCP port keeps changing... No real way to point to one specific user-agent

Also, the I-D refers to another problem when the user-agent keeps changing of IP address ;-)

From: "Walter H." <[email-masked]<mailto:[email-masked]>>
Organization: Home
Date: samedi 4 avril 2015 11:49
To: Max Bruce <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Linking a cookie to an IP address is a very bad in 2015...
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Sat, 4 Apr 2015 09:49:55 +0000

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. <[email-masked]<mailto:[email-masked]>> 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?

---

From: Jim Manico <[email-masked]>
Date: Sat, 4 Apr 2015 09:12:11 -0700

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. 

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

> On Apr 4, 2015, at 3:18 AM, Max Bruce <[email-masked]> 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. <[email-masked]> wrote:
>>> On Fri, Apr 3, 2015 at 12:10 AM, Walter H. <[email-masked]> wrote:

---

From: "Walter H." <[email-masked]>
Date: Sat, 04 Apr 2015 18:15:13 +0200

I see, in case the tcp-connection is lost/closed, does this also mean 
the https session is closed?
or in other words: it is no problem, closing a socket and opening another;
is this true during a http and/or https-session?

On 04.04.2015 12:18, Max Bruce 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. <[email-masked] 
>     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 ...
>
>>     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.
>>     <[email-masked] <mailto:[email-masked]>>
>>     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.

---

From: "Walter H." <[email-masked]>
Date: Sat, 04 Apr 2015 18:51:31 +0200

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> 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.
>>
>>     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
>>>>         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.

---

From: Jim Manico <[email-masked]>
Date: Sat, 4 Apr 2015 09:59:11 -0700

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
(808) 652-3805

> On Apr 4, 2015, at 9:51 AM, Walter H. <[email-masked]> wrote:
> 
> as long as your device only changes the location in small distances, so that it stays inside the same mobile network operator,
> 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 
> think of what can happen, so that you bring the "login-page" instead of going further in the session;

---

From: Max Bruce <[email-masked]>
Date: Sat, 4 Apr 2015 13:48:37 -0700

Yes, I would think it wouldn't be very robust if socket closing ruined your
sessions.

---

From: Max Bruce <[email-masked]>
Date: Sat, 4 Apr 2015 13:47:46 -0700

That isn't an issue for a session that's supposed to end 5 minutes or so
after it begins.

On Sat, Apr 4, 2015 at 9:12 AM, Jim Manico <[email-masked]> wrote:

> 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.
>
> --
> Jim Manico
> @Manicode
> (808) 652-3805
>

---

From: Jim Manico <[email-masked]>
Date: Sat, 4 Apr 2015 14:02:11 -0700

It's not •likely• to be an issue for short lived sessions but it could happen.

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

> On Apr 4, 2015, at 1:47 PM, Max Bruce <[email-masked]> wrote:
> 
> That isn't an issue for a session that's supposed to end 5 minutes or so after it begins.
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 4 Apr 2015 21:46:13 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: samedi 4 avril 2015 18:59
To: "Walter H." <[email-masked]<mailto:[email-masked]>>
Cc: Max Bruce <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Linking a cookie to an IP address is a very bad in 2015...
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-Date: samedi 4 avril 2015 18:59

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

source-ip:source-port
user-agent

screen resolution

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

On Sat, Apr 4, 2015 at 2:49 AM, Walter H. <[email-masked]<mailto:[email-masked]>> 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?

---

From: "Walter H." <[email-masked]>
Date: Sun, 05 Apr 2015 10:06:22 +0200

Are you sure this is only NAT and not some proxies?
(this could be transparent proxies)

in case your public IP address changes even your phone RFC 1918 address 
doen't change can have a logic reason: it is not said that there is only 
one node for one mobile operator; it can have two or more nodes; and 
every node has the same DHCP range; and now you move from one node to 
the next node; in case the RFC1918 address from the first node is 
available at the second node, there is no reason to give you a different 
RFC1918 address, but you have a different public address; the other 
case, that your RFC1918 address from the first node is already taken at 
the second node, would not make any difference; you get a different 
RFC1918 address, too;

when talking about Thalys, there you could probably have a seat with a 
power plug for a portable computer (please don't talk about phones)
and maybe the train offers a public WLAN, too;

now compare someone using this with a portable computer 
(notebook/laptop) and you with your phone;
and now think of your session and maybe a VPN tunnel between this 
portable computer and his/her home/company;
your session cannot be any longer as the VPN tunnel stays available 
without having to reinitiate because of "breakdowns"

these "breakdowns" are: change of RFC1918 address and change of public 
address;
(would be strange if these are not)

On 04.04.2015 23:46, Eric Vyncke (evyncke) wrote:
> 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).
>