On Mon, Sep 30, 2013 at 4:51 PM, Tjerk Meesters <tjerk.meest...@gmail.com>wrote:
> On Sat, Sep 28, 2013 at 6:47 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >> Hi Leigh, >> >> On Fri, Sep 27, 2013 at 7:12 PM, Leigh <lei...@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. >>> >> >> There are 2 improvements >> >> 1. Generally speaking, more frequent session ID regeneration is more >> security. >> > > This could make it more difficult for an attacker to take advantage, but > then I would like to see other changes as well, for instance: > > a) Enable session.use_strict_mode by default. > b) Enable session.use_only_cookies by default > c) Enable session.cookie_httponly by default. > d) Use a stronger session.hash_function with more > session.hash_bits_per_character by default. > e) Enable session.cookie_secure on secure connections (I know this is not > going to be fool proof). > > There are probably more settings we could change to more security aware > values. > > I was thinking propose RFC some of these changes. > 2. Detection/indication of attacks is good for security. >> > > This is an interesting aspect; when an old session identifier is > presented, from the end-user's perspective, either: > a) They get redirected to the site's login page; the user gets redirected > to the login page and unless they suspect their session was compromised (if > that's indeed what happened), they will sign in again (the browser may have > remembered the credentials, so it's a single click operation and they're > back), or > > b) If the system uses a (naive) "remember me" feature, a new session gets > created automatically and they don't notice a thing. > > From the server-side's perspective, the cookie value could simply not be > found, assuming that the regeneration also deletes the previous session > data; there's no discernible difference between an old session and a > compromised session afaict. This would be a different story if the session > engine would keep track of past values as well. > > Btw, what I'm also missing from this proposal is the ability to hash > against other factors, i.e. user agent. ISP's may use a transparent HTTP(s) > proxy, most companies use an NAT, so being able to detect user agent > changes may improve detection further. > > The bottom line is: if the system can make it easier to detect intrusion, > it should be in the system and it should be easy :) > I agree. We can do many more things to make session more secure. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
