Re: Regenerating session ID automatically when IP address has changed

From: Date: Fri, 27 Sep 2013 11:00:24 +0000
Subject: Re: Regenerating session ID automatically when IP address has changed
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-69391@lists.php.net to get a copy of this message
On 27 September 2013 12:54, Leigh <leight@gmail.com> wrote: > On 27 September 2013 11:39, Peter Lind <peter.e.lind@gmail.com> wrote: > > On 27 September 2013 12:12, Leigh <leight@gmail.com> wrote: > >> > >> 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. > > > > 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 > > And what is done to invalidate the session now gained by the attacker? > Since this is a proposal to handle such things internally. > > And what is done when the user thinks everything is fine and dandy? My point was that the scenario you created did not pose a problem - if anything it would be a benefit (as you actually *can* detect some problems now). Do you really think random user X will think something is wrong beyond > the site they were using just kicking them out for no reason? So now > what do they do now? Log in again? The attacker still has the > previously valid session, so nothing is gained. > > That's for the userland code to decide. > This is exactly why this kind of logic belongs as user code. We're > starting to define rules for a system that should be agnostic to how > it is being used. > I would agree. I was just pointing out that your example was not in fact much of an argument against the proposal. Regards Peter -- <hype> WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 </hype>

« previous php.internals (#69391) next »