Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72051
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPhkiZwDgMqHuyTN89_0yJKYnusmELfLR0DV2_i-zoHKg2=GoA@mail.gmail.com>
References: <CAPhkiZyMULFgCoTaaqtwx_34ovTX-36dTdVUgMXE_aWPd5O+WQ@mail.gmail.com>
	<CAH-PCH71z58Ghhg9koPRM8RXYk1bXWSW_ogJqY1TpUAQK8pu6A@mail.gmail.com>
	<CAPhkiZwsS6wEijXJGHx03f7zf9OFDg9G_2NwMqNDZSmmPsBBZA@mail.gmail.com>
	<52E319F2.8080705@sugarcrm.com>
	<CAPhkiZy7+6hGakv4bXVR2djx18H+s_69OUoyPSjd=JaUVVp61Q@mail.gmail.com>
	<52E3959D.4000103@sugarcrm.com>
	<CAGa2bXZGujJXHpNv3veVg9u8QxRUW=Q__df145x1vJh+KyT3dQ@mail.gmail.com>
	<52E45A5D.7020807@sugarcrm.com>
	<CAGa2bXbDCY3vG-VThsfbRVmZhs7jWzAYu0XDDyq2-WVz_OeAkg@mail.gmail.com>
	<CAGa2bXbMQzydCTG=bZ3XLzxgLBSzwQ6BUsJGUUtmx2kf=YEXoQ@mail.gmail.com>
	<CAPhkiZwDgMqHuyTN89_0yJKYnusmELfLR0DV2_i-zoHKg2=GoA@mail.gmail.com>
Date: Mon, 3 Feb 2014 09:50:59 +0200
Message-ID: <CAPhkiZwGbx9xZCd2CKmYJuYOFpV95Pm7HUxbs5brBEUYrBZc7w@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Session IP address matching
From: narf@devilix.net (Andrey Andreev)

> If you force this measure on /wp-admin or equivalent, you'll never
> retain customers. (Some frameworks offer this option in userland
> anyway -- plus the absolutely _vital_ ability for the user to turn it
> off him/herself.)

Why is everybody talking like I'm proposing to change this internally
and not leave any option to turn it off? This is a new option,
defaulting to Off.

> A special case where the feature might do more good than harm is when
> both server and clients are on the same LAN with static IPs. If the
> organization is computing/scientific in nature it might be reasonable
> to expect inside jobs using network taps, bespoke interception boxes
> -- or whatever -- to intercept SSL and also hijack per-request session
> IDs (perhaps by timing for end-of-day or something). The extra IP
> check might then be practical protection. But unless the internal
> systems saw seriously high traffic surely a userland implementation
> would work just fine.

Server and clients being on the same LAN is (of course) what I mean
when I mention an intranet. IPs don't have to be static, although they
usually are in such an environment.
I also don't understand why a non-computing/scientific organization
should neglect security. Yes, probablility of inside jobs is
different, but still - one tech savvy employee in a bad mood is
sufficient.

> (My) bottom line is that putting this feature in core is a clear
> recipe for disaster. Most PHP users, let alone the "app deployer" type
> of users, don't know s**t about HTTP or TCP/IP. The moment turning on
> this feature gets mistakenly documented as a best practice on some
> excited newbie's blog, or somebody's downvoted-but-not-deleted
> StackOverflow post, you've caused way more harm than good. Look at it
> this way: if even *Stefan* (Suhosin) recommends conservative use, take
> that caveat very seriously.

So document it properly. User's lack of knowledge shouldn't be a
reason to exclude a feature.

Cheers,
Andrey.