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.
Thread (30 messages)