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

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

On Sat, Apr 4, 2015 at 9:15 AM, Walter H. <Walter.H@mathemainzel.info>
wrote:

>  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. <Walter.H@mathemainzel.info>
> 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. <Walter.H@mathemainzel.info>
> 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?
>
>
>
>
>
>