Re: [RFC] Secure Session Module Options by Default

Hi, On Mon, Feb 3, 2014 at 12:18 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Andrey, > > On Mon, Feb 3, 2014 at 4:31 PM, Andrey Andreev <narf@devilix.net> wrote: >> >> 'use_strict_mode' is supposed to generate a new session ID when the >> application receives a session cookie with an invalid (non-existing) >> session ID. >> I don't think that it should've ever changed the behavior of >> session_id() and I'd rather consider it a bug if it doesn't allow it >> to set the new session ID. > > > I can understand your opinion. Yet, it would be better for users to have > securely prefixed session ID. IMHO. > > string session_id('PREFIX_', TRUE); > > This does not set insecure session ID, since it only adds prefix to > generated session ID. I was just pointing out that 'use_strict_mode' shouldn't change the behavior of session_id(). In other words, you don't need a "force" option, because passing a custom made ID by itself already tells it to force something. Don't know why you're talking about prefixes here ... nothing to do with security. >> 'hash_bits_per_character' has nothing to do with security and its only >> useful purpose that I could think of is maintainig BC for >> database-stored session data, where i.e. the ID used to be an md5 hash >> and and switching to sha1 would require altering the field length to >> 40. Increasing hash_bit_per_character in that case would allow a >> sha-1-sized hash to be stored in 32 characters. >> Other than that (and probably some crazy traffic volume-related >> micro-optimization), it's pretty useless. > > > Since the RFC is proposing stronger hash function as NIST suggests, > session ID needs to have longer hash bits. To reduce size of session ID, > larger hash bits is proposed. Similar reason you explained. > > Some user may have limited storage size for session ID. However, it's > not a good excuse keeping weaker setting. Users need weaker settings > should set values for their own. IMHO. I'm not sure I understand what you're saying. If it is that you want to maintain BC on the session ID length - sure, I see how that would be nice to have. Not that I have any authority around here, but I'd recommend updating the RFC to properly explain this. As it stands, it makes it almost makes it look like incrementing the 'hash_bits_per_character' value by itself increases security, and it doesn't. :) >> That "allow an underscore when hash_bits_per_character=6" is also not >> in the scope of security and the hash function itself wouldn't >> generate an underscore, so ... what has it got to do with anything? > > > If hash_bits_per_character=6, files save handler uses all chars for session > ID and users cannot have prefix delimiter char. User may use string offset, > though. That's the reason why there is '_' proposal. This is hard to follow, I really don't understand why we're talking about prefixing here at all and how does it relate to 'hash_bits_per_character' or security. Cheers, Andrey.