Re: Session IP address matching
> 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.
Thread (29 messages)