Everything

php

[RFC] Secure Session Module Options by Default

php.internals

Yasuo Ohgaki

12 years ago

Hi all,

Secure Session Module Options by Default
https://wiki.php.net/rfc/secure-session-options-by-default

Session is core of web security. Therefore, default should be
as secure as possible by default.

I'll open vote next week, please send comments now.

Thank you.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

12 years ago

Hi!

> Secure Session Module Options by Default
> https://wiki.php.net/rfc/secure-session-options-by-default

use_strict_mode - I'm not sure I understand what "Change session_id() to
allow any id regardless of this mode." means. Since there's no patch
attached, could you explain the change in more detail?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Yasuo Ohgaki

12 years ago

Hi Stas,

On Sun, Feb 2, 2014 at 7:52 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > Secure Session Module Options by Default
> > https://wiki.php.net/rfc/secure-session-options-by-default
>
> use_strict_mode - I'm not sure I understand what "Change session_id() to
> allow any id regardless of this mode." means. Since there's no patch
> attached, could you explain the change in more detail?

When use_strice_mode=On,

session_id($some_new_id);

will generate random session ID, since there is no initialized session data
for it. (This is what use_strict_mode=On supposed to do)

However, user may set their own session ID which contains some data in
session ID name via session_create_id([string $prefix]). e.g. time
created/regenerated/etc.

To set user defined session ID, user has to do

ini_set('session.use_strict_mode', FALSE);
session_id(session_create_id('SOME-USEFUL-PREFIX'));

With this change, user could do

session_id(session_create_id('SOME-USEFUL-PREFIX'));

regardless of INI settings. session_id() is changed to modify
'session.use_strict_mode' INI to off internally. This change is not
mandatory as user may change INI by themselves. It's for convenience. I
don't mind at all withdrawing this change from the RFC.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Yasuo Ohgaki

12 years ago

Hi Stas,

On Sun, Feb 2, 2014 at 8:59 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> To set user defined session ID, user has to do
>
> ini_set('session.use_strict_mode', FALSE);
> session_id(session_create_id('SOME-USEFUL-PREFIX'));
>
> With this change, user could do
>
> session_id(session_create_id('SOME-USEFUL-PREFIX'));
>
> regardless of INI settings. session_id() is changed to modify
> 'session.use_strict_mode' INI to off internally. This change is not
> mandatory as user may change INI by themselves. It's for convenience. I
> don't mind at all withdrawing this change from the RFC.
>

Users might be setting unsafe session ID using session_id(), adding
optional $force_id parameter to session_id() is better.

$force_id = TRUE;
session_id(session_create_id('SOME-USEFUL-PREFIX'), $force_id);

It may prevent setting unsafe ID by mistake.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

12 years ago

Hi!

> To set user defined session ID, user has to do
>
> ini_set('session.use_strict_mode', FALSE);
> session_id(session_create_id('SOME-USEFUL-PREFIX'));
>
> With this change, user could do
>
> session_id(session_create_id('SOME-USEFUL-PREFIX'));

I think having parameter on session_id is preferable. What happens if
this is not set and you do session_id('blah') - does it start the
session? What is returned from session_id as the result?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Yasuo Ohgaki

12 years ago

On Sun, Feb 2, 2014 at 4:14 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

>
> > To set user defined session ID, user has to do
> >
> > ini_set('session.use_strict_mode', FALSE);
> > session_id(session_create_id('SOME-USEFUL-PREFIX'));
> >
> > With this change, user could do
> >
> > session_id(session_create_id('SOME-USEFUL-PREFIX'));
>
> I think having parameter on session_id is preferable. What happens if
> this is not set and you do session_id('blah') - does it start the
> session? What is returned from session_id as the result?

It could have signature like

string session_id(string $prefix_or_id [, bool $use_prefix]);

and

session_id('SOME-PREFIX-', TRUE); // return
SOME-PREFIX-xxxxxxxxxxxxxxxxxxxxx

session_id() returns current PS(id)  always.
When there is active session, session_id('something') sets PS(id).
It set PS(id) and it will be used as session ID if session is closed and
open again.
We have to decide what we will do about use_strict_mode behavior.
It may be easier automatically set use_strict_mode=FALSE.

I would like to expand uniqid() or create new function that returns
secure random string, so session_create_id() is not mandatory.

I agree
string session_id(string $prefix_or_id [, bool $use_prefix]);
simpler. Simpler is better :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Yasuo Ohgaki

12 years ago

On Sun, Feb 2, 2014 at 6:50 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> When there is active session, session_id('something') sets PS(id).
>

Correction.

session_id('something') sets PS(id).

Regardless of session state.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

12 years ago

Hi!

> It could have signature like
>
> string session_id(string $prefix_or_id [, bool $use_prefix]);

I'm not sure what prefix has to do with this RFC. Didn't we talk about
secure setting? Where the prefix came from and why we need the prefix at
all?

> We have to decide what we will do about use_strict_mode behavior.
> It may be easier automatically set use_strict_mode=FALSE.

I'm not sure I understand. So if strict mode is on, when I do
session_id('foo') and session with ID foo does not exist, what would
happen? Would session_start() create it or would it generate new ID,
effectively ignoring my session_id command silently?

> I would like to expand uniqid() or create new function that returns
> secure random string, so session_create_id() is not mandatory.

Don't we have such function already?
http://us1.php.net/manual/en/function.mcrypt-create-iv.php

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Yasuo Ohgaki

12 years ago

Hi Stas,

On Sun, Feb 2, 2014 at 7:25 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > It could have signature like
> >
> > string session_id(string $prefix_or_id [, bool $use_prefix]);
>
> I'm not sure what prefix has to do with this RFC. Didn't we talk about
> secure setting? Where the prefix came from and why we need the prefix at
> all?
>

I see some users are generating unsafe session ID. Purpose of change is
not to generate insecure ID when user want some prefix in session ID.

>
> > We have to decide what we will do about use_strict_mode behavior.
> > It may be easier automatically set use_strict_mode=FALSE.
>
> I'm not sure I understand. So if strict mode is on, when I do
> session_id('foo') and session with ID foo does not exist, what would
> happen? Would session_start() create it or would it generate new ID,
> effectively ignoring my session_id command silently?
>

Yes.
Currently, if 'foo' is not there already, session_id('foo') does not set
session ID, but creates new random session ID when use_strice_mode=on.

string session_id(string $prefix_or_id [, bool $use_prefix=FALSE]);

$use_prefix=TRUE will bypass use_strict_mode=on.

>
> > I would like to expand uniqid() or create new function that returns
> > secure random string, so session_create_id() is not mandatory.
>
> Don't we have such function already?
> http://us1.php.net/manual/en/function.mcrypt-create-iv.php

As discussed in other thread, mcrypt_create_iv() is good one, but
it has some limitations. That's the reason why I think it would be
better to have function that generates secure random ID some how.

Anyway, it is time to compile openssl module by default. IMHO.
It makes security a lot simpler/easier for both users and internal
developers.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

12 years ago

Hi!

> I see some users are generating unsafe session ID. Purpose of change is
> not to generate insecure ID when user want some prefix in session ID.

What's "insecure session ID" and how it is related to the matter we are
discussing?

> Yes.
> Currently, if 'foo' is not there already, session_id('foo') does not set
> session ID, but creates new random session ID when use_strice_mode=on.
>
> string session_id(string $prefix_or_id [, bool $use_prefix=FALSE]);
>
> $use_prefix=TRUE will bypass use_strict_mode=on.

I still don't understand what use_prefix has to do with secure session
and why use_prefix would bypass strict mode. Something is missing here
for me. Could you give some more detailed explanation of what you're
trying to do here?

> As discussed in other thread, mcrypt_create_iv() is good one, but
> it has some limitations. That's the reason why I think it would be
> better to have function that generates secure random ID some how.

We have two functions that generate random sequences - one in openssl
and one in mcrypt. Why we need a third one?

> Anyway, it is time to compile openssl module by default. IMHO.

Why we must control what the user compiles? The users that know what
they're doing will compile it anyway, the users that don't will use
distros which couldn't care less about our defaults and build all
extensions separately anyway. I don't see which problem you're trying to
fix here.

> It makes security a lot simpler/easier for both users and internal
> developers.

What exactly is hard now but becomes easier? Typing --with-openssl is
not hard.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Yasuo Ohgaki

12 years ago

Hi Stas,

On Mon, Feb 3, 2014 at 5:23 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > I see some users are generating unsafe session ID. Purpose of change is
> > not to generate insecure ID when user want some prefix in session ID.
>
> What's "insecure session ID" and how it is related to the matter we are
> discussing?

If there is not a easy way to create secure session ID (Currently, we
don't),
users may generate session ID by their own which may be insecure.

>  > Yes.
> > Currently, if 'foo' is not there already, session_id('foo') does not set
> > session ID, but creates new random session ID when use_strice_mode=on.
> >
> > string session_id(string $prefix_or_id [, bool $use_prefix=FALSE]);
> >
> > $use_prefix=TRUE will bypass use_strict_mode=on.
>
> I still don't understand what use_prefix has to do with secure session
> and why use_prefix would bypass strict mode. Something is missing here
> for me. Could you give some more detailed explanation of what you're
> trying to do here?
>

I see codes that set insecure session ID. use_strict_mode=on is supposed
to prevent it. However, there are users who want to have prefix as explained
before.

They would like to know session creation time, owner without actually
reading
session data for performance reasons.

I think this is valid use case of prefixed session ID.

> > As discussed in other thread, mcrypt_create_iv() is good one, but
> > it has some limitations. That's the reason why I think it would be
> > better to have function that generates secure random ID some how.
>
> We have two functions that generate random sequences - one in openssl
> and one in mcrypt. Why we need a third one?
>

This does not relates for this RFC anymore, since session_id(PREFIX, TRUE)
address creating secure session.

>
> > Anyway, it is time to compile openssl module by default. IMHO.
>
> Why we must control what the user compiles? The users that know what
> they're doing will compile it anyway, the users that don't will use
> distros which couldn't care less about our defaults and build all
> extensions separately anyway. I don't see which problem you're trying to
> fix here.
>

For instance, isn't it nice to have hardware AES available for
applications, is it?
Developers may assume users to load required extension, though.

> It makes security a lot simpler/easier for both users and internal
> > developers.
>
> What exactly is hard now but becomes easier? Typing --with-openssl is
> not hard.

I see many use cases of random bytes and encryption.

For example, there is no 'standard' function generating secure random
bytes now. We could say use of uniqid() as a secure random source is
bad, but isn't it bad that we don't provide standard function for it?

Available optionally and available always is different. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Pierre Joye

12 years ago

On Feb 3, 2014 11:36 AM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:

>
> Hi Stas,
>
> On Mon, Feb 3, 2014 at 5:23 PM, Stas Malyshev <smalyshev@sugarcrm.com
>wrote:
>
> > > I see some users are generating unsafe session ID. Purpose of change

is

> > > not to generate insecure ID when user want some prefix in session ID.
> >
> > What's "insecure session ID" and how it is related to the matter we are
> > discussing?
>
>
> If there is not a easy way to create secure session ID (Currently, we
> don't),
> users may generate session ID by their own which may be insecure.

That's exactly the point. Sessions have options to make them more secure
(entropy, hash). Maybe the default should be improved. As far as I remember
it is not possible anymore to build php without providing a valid entropy
source.

Cheers,
Pierre

Lester Caine

12 years ago

Yasuo Ohgaki wrote:

>>> I see some users are generating unsafe session ID. Purpose of change is
>>> > >not to generate insecure ID when user want some prefix in session ID.
>> >
>> >What's "insecure session ID" and how it is related to the matter we are
>> >discussing?
>
> If there is not a easy way to create secure session ID (Currently, we
> don't), users may generate session ID by their own which may be insecure.

Simple question ... does it actually matter?
If a session id is simply used for navigating a visit to a site then as long as
it works it's fine? If *I* am working with a secure site then I have another
level of security via a VPN connection. As an intermediate for secure financial
transactions, it's the service providers who dictate the security used?
Again we seem to be targeting things which are under rules which may be dictated
by third party requirements, and third party tools such as ssh?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Yasuo Ohgaki

12 years ago

Hi all,

On Sun, Feb 2, 2014 at 7:33 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Secure Session Module Options by Default
> https://wiki.php.net/rfc/secure-session-options-by-default
>
> Session is core of web security. Therefore, default should be
> as secure as possible by default.
>
> I'll open vote next week, please send comments now.
>

As many of already knew, use of SHA-1 is deprecated for security related
use by NIST.

"applications that require collision resistance as soon as practical, and
must use the SHA-2 family of hash functions for these applications after
2010. "
http://csrc.nist.gov/groups/ST/hash/policy_2006.html

Current files save handler detects collision and it is out of NIST
requirement regardless of hash function. Collision detection is up to save
handler now. It could be check with newer session module code using
PS_VALIDATE_SID_FUNC(). This API is included in the patch for

https://wiki.php.net/rfc/session-lock-ini

If 3rd party save handler supports PS_VALIDATE_FUNC(), collision detection
can be done at session module.

This RFC may be better to include this change (collision detection) also.

AND/OR

We may use SHA-256 as the default.
This may be preferred since NIST discourages use of SHA-1 anyway.

Regards,

P.S. It may be too late to change. SHA-3 is coming now.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Yasuo Ohgaki

12 years ago

Hi all,
On Sun, Feb 2, 2014 at 7:33 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Secure Session Module Options by Default
> https://wiki.php.net/rfc/secure-session-options-by-default
>
> Session is core of web security. Therefore, default should be
> as secure as possible by default.
>
> I'll open vote next week, please send comments now.
>

I've added new INI option for security reason. (Timing attack mitigation)

**session_id_length** minimum session ID length to mitigate timing attack.
26 for PHP 5.3/5.4/5.5. 52 for 5.6.

I'll add new value(int) at the end of ps_globals for released versions.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Yasuo Ohgaki

12 years ago

Hi all,

On Thu, Feb 6, 2014 at 3:15 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> On Sun, Feb 2, 2014 at 7:33 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Secure Session Module Options by Default
>> https://wiki.php.net/rfc/secure-session-options-by-default
>>
>> Session is core of web security. Therefore, default should be
>> as secure as possible by default.
>>
>> I'll open vote next week, please send comments now.
>>
>
> I've added new INI option for security reason. (Timing attack mitigation)
>
> **session_id_length** minimum session ID length to mitigate timing attack.
> 26 for PHP 5.3/5.4/5.5. 52 for 5.6.
>

I need information about PHP distributions.
Does anyone know if there is PHP distributions that provide hash module as
*.(so|dll)?
If there is, I have to change this INI value.

Thank you!

--
Yasuo Ohgaki
yohgaki@ohgaki.net