Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69360
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender)
Date: Thu, 26 Sep 2013 18:39:03 -0400
Reply-To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Message-ID: <528653009.20130926183903@cypressintegrated.com>
To: Tjerk Meesters <internals@lists.php.net>
In-Reply-To: <CAHMUw2EQuT-y2Ho85QXhDdtysTWC=4FyY4nK9i-yR7qGqk6M=Q@mail.gmail.com>
References: <CAGa2bXbh6dOf41nZ0r-RuRtkCuuiA=r=SnxS+A1+GgqFXPGOWQ@mail.gmail.com> <CABBJUpdNr6McK6Q4qtztiYYG9CKZF7AeUdvo3YM+W0S87f8nDg@mail.gmail.com> <CAPwsocEwM_A3YraxZmJEXjBxaGgTZhfv711801bwtHLfJfNh+Q@mail.gmail.com> <CAHMUw2EQuT-y2Ho85QXhDdtysTWC=4FyY4nK9i-yR7qGqk6M=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman)

> Let's be clear here: this won't happen (in most cases), because the client
> will simply get a new cookie and the session will keep working; it's like
> what you would implement if your user level goes from anonymous to logged
> in and vice versa.

I'm glad you addressed this because I'd been thinking that a lot of
people were misinterpreting the common (non-hijacked) scenario,
thinking that session regeneration meant a client-facing logout, which
of course it doesn't as long as the client uses the new id on the next
request.

The concerns about forward and reverse proxies (you would typically
use x-forwarded-for in the second case) seem also off-topic; even
going through multiple proxies of each type won't matter as long as
cache privacy is respected and the end user receives the new id. (One
can argue that the more individual HTTP circuits you need to traverse,
the more likely packets will be dropped, but that seems excessively
paranoid for discussing this feature. I do agree with the server-side
performance impact of very frequent changes on the forward proxy side
forcing thrashing of the session store.)

But the main problem, to me, is handling the aftermath of a hijack
detected in this way. First, the UX factor: is it really feasible to
provide the user with feedback like "You have been logged out for your
protection because your session may have been hijacked by another user
on your network -- now go find out which guy in the coffeeshop is
listening!" That's quite a challenge. I'm sure many of us have seen
the white hat studies of just how easy it is to get people to ignore
warnings in the browser chrome or from runtimes like Java and Flash:
look up the guy who got his office of "techie" Tor users to ignore
redirects between https and http!

I suppose if the victim accepts that something security-related has
gone wrong, they don't have to understand what it was as long they can
do something in response, and the most actionable advice is "You MUST
leave this network immediately because it's insecure." But many people
will ignore this message, and then (if I'm not misunderstanding the
intent here) they will be prompted to log in again, on the same
network. Problem: now the person who's still sniffing the network, who
might have had only their session info before, can possibly sniff
their username and hashed password, which is potentially much, much
worse! (If a fresh login is over SSL but regular traffic is not, and
the attacker was only using primitive sniffing of plaintext, that
would be a mitigator.)

Assuming a fresh login is not itself vulnerable, after authentication,
do you offer (or force?) all other sessions linked to the user id to
be expired? If so, this would of course include a legit session in
another browser or device.

In sum, I'm curious about the expected use of the feature _after_ the
alert goes off. yohgaki?

> Aha! I'm glad that you brought up mobile devices, because for those it's
> more likely that in certain cases the updated cookie is not received while
> the server believes that it was; scenario: "I stepped into an elevator and
> was disconnected when I got out.". This makes it an unattractive option to
> have enabled by default.

Maybe the feature just needs to be disabled by default, yet not being
able to protect against mobile session hijacking because of fear of
lost responses seems like weakening it to the point of uselessness. I
don't know the actual numbers, but I worry most about my users using
their tablets in a coffeshop or hotel and if I had to turn this off
for most mobile browsers, that would be a bit silly (AFAIK, there's
not yet a universally-supported way of distinguishing wifi from mobile
data, i.e. navigator.connection.type).

We all accept that request-response cycles don't always complete on
mobile, particularly on 3G, but I haven't yet seen anyone get metrics
on how common it is based on network behavior _and_ user movement...
also figuring that huge packet loss, once felt by the user, influences
people to decide the network is effectively "down" and to not attempt
any more requests for a while. It would make for an interesting study
and forcibly changing a test cookie on every request (regardless of IP
change) would be part of figuring out how bad the real-world situation
is, at least for a given app and its users.

-- S.