On 27 September 2013 12:12, Leigh <lei...@gmail.com> wrote: > On 26 September 2013 11:32, Tjerk Meesters <tjerk.meest...@gmail.com> > wrote: > > > > On Thu, Sep 26, 2013 at 6:19 PM, Leigh <lei...@gmail.com> wrote: > >> > >> There's several scenarios where a users IP changes and you don't want to > >> drop their session. (That doesn't mean it should simply have an option > to > >> disable it either) > > > > > > 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. > > Right, so maybe I misunderstood the intent of this. > > I was reading it as: valid SID on new IP = drop session, which to me > seems like the more "secure" approach. > > What you're saying is is when a valid SID is supplied on a new IP, you > regenerate the SID and the session continues to be valid on the new > IP? > > So on a successful session hijack (correct SID, new IP) the attacker > gets a new SID and keeps the valid session while the legitimate user > gets kicked out. > > Not seeing how that improves things at all. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > In your scenario, user gets booted and thus knows somethings wrong. Much better than the attacker hijacking the session without the user knowing anything at all.
Regards Peter -- <hype> WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 </hype>
