Re: [RFC] Secure Session Module Options by Default

Hi again, >> I am not referring to an old RFC, I'm saying this parameter is pointless. >> What difference does it make at all? How does session_id() work with >> and without it? > > > Original proposal was > > session_id('SOME_USEFUL_PREFIX' . session_create_id()); > > and allow to set ID. New one should be > > bool session_id(string $new_id_or_prefix [, bool $use_prefix=FALSE]); > > (I thought I've updated the signature. It was old...) > It supposed to used like > > session_id('PREFIX_', TRUE) // retunrs PREFIX_SECURE-SID > > New API would not allow insecure session ID when use_strict_mode=on while > allowing user defined prefix for session ID. You're not getting what I mean at all. use_strict_mode should only validate cookie input, that's what it is meant for: >> I'm not ignoring anything, I'm just saying this should be in a separate >> RFC. >> > > I have too many RFCs already... > I would like to reduce number of RFCs. Would you like it if people vote 'No' on this RFC because they like the setting changes, but not the proposed session_id() parameter? That's how I would vote if I could. :) >> See my previous comment above. >> You didn't chose a wrong name, you seem to have done a 2-in-1 RFC and >> that's not the right approach IMO. At the very least - it's obviously >> confusing and most of what you've said in this conversation isn't >> described in the RFC at all. > > > To me, it's the same objective that make session usage as secure as > possible. > I don't see reason to make 2 patches/RFC for making session module secure. > Perhaps, better title would be > > "Make session options/API as secure as possible" > > 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. It's not the same thing, not even the same category. On the '_' character: Any character passed to session_id() should be allowed, depending on hash_bits_per_character and just for the underscore doesn't sound good to me. Cheers, Andrey.