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.