Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71569 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4483 invoked from network); 25 Jan 2014 21:30:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jan 2014 21:30:46 -0000 Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Received: from [173.1.104.101] ([173.1.104.101:56827] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EF/B3-19300-50D24E25 for ; Sat, 25 Jan 2014 16:30:46 -0500 Received: from gw02 ([24.221.227.153]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id LWD68238 for ; Sat, 25 Jan 2014 13:30:38 -0800 Date: Sat, 25 Jan 2014 16:07:39 -0500 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <1737400074.20140125160739@cypressintegrated.com> To: Rick Widmer In-Reply-To: <52E42016.2050507@developersdesk.com> References: <52E31FB6.9010408@ajf.me> <52E3C606.6000301@heigl.org> <52E42016.2050507@developersdesk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: swhitemanlistens-software@cypressintegrated.com Subject: Re: [PHP-DEV] Session IP address matching From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) > I've seen the initial page and subsequent image requests for a single > page load come from different IP addresses. It certainly happens. Ultimately, though, the question isn't just about ultradynamic IPs. It's simply about the acceptable percentage of humans whose session expiry will be 1 or 2 minutes when everybody else's is 10m or more. These people will be unwilling to use your site if you implement this feature and do not allow the _user_ to turn it off him/herself if necessary. For our site, a team-based web app, that percentage is *zero*. We cannot under any circumstances prohibit somebody from inviting another user who happens to roam on cellular or heavily proxied networks. I must also allow the team manager to easily manage such a setting on behalf of their reports, who are frequently not as technically savvy and certainly don't want to race to get to their User Profile area in time. We're also addressing attackers who have sniffed your encrypted traffic and can wedge in-between your constantly-changing session IDs -- significant security measures that have no such collateral damage. I guess the attackers have client certs covered as well. (Of course, if they have this level of ownership, there's a good chance they're being NATted through your same source IP anyway!) Is it worth shedding potential users, potentially killing your entire business if it is collaborative in nature, in order to thwart this probably-null set of potential attackers? I say no, and any security auditor who automatically penalizes you if you don't say "yes" isn't doing his/her job. -- Sandy