Re: [RFC] Secure Session Module Options by Default

From: Date: Fri, 04 Apr 2014 09:14:07 +0000
Subject: Re: [RFC] Secure Session Module Options by Default
References: 1 2 3 4 5 6 7 8 9 10 11  Groups: php.internals 
Request: Send a blank email to internals+get-73592@lists.php.net to get a copy of this message
Hi all, On Thu, Apr 3, 2014 at 6:31 PM, Andrey Andreev <narf@devilix.net> wrote: > > >> > Regarding "_" addition to files save handler, it may not be RFC issue > as > >> > it > >> > does not break anything at all. Just an simple addition of safe char > >> > that > >> > is needed for new safe prefixed session ID with hash bits=6. It may > >> > apply > >> > even prefixed session. I think there are many changes like this w/o > RFC. > >> > > >> > I tried to write RFC to be minimum and sufficient. I should add more > >> > description > >> > if it is not. Or add link of this thread. I think it's preferred way. > >> > >> Changing default settings in the proposed way makes ext/session > >> more secure by default. > >> > >> Adding a new parameter to session_id() only gives users an easier > >> way to do complete a task that they otherwise *could* do the wrong > >> way. > >> > >> The first has real, straight-forward impact on security and doesn't > >> change existing functionality. > >> The second only *might* lead to some userland code being more secure > >> and it is questionable if that's the proper tool for the job. I for > >> one would like more tools that allow me to change a session's > >> behavior, but a prefix is not one of them. > > > > > > If you handle millions of sessions and would like to find specific > > active sessions with marginal overhead, prefixing is the way to > > go. Many users may not need it, but there are users who need. > > Or, you could prefix (or add another field to check against) it in > storage, but leave the session ID itself untouched. That's not the > point though ... this just isn't a security feature and the RFC is > about improving security. > > Can we move this forward now? I don't think there's anything more to > discuss. > Btw, I'm still a proponent of changing hash_bits_per_character as > well, but IMO that may be done separately, without an RFC. Sure. These are simple changes for better session security. I have to update RFC so that everyone understand side effects of these changes. hash_bits_per_characters may stay the same and additional char to files save handler could be added simply. I'll update the RFC weekend, hopefully. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net

« previous php.internals (#73592) next »