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
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
Hi Stas,
On Sun, Feb 2, 2014 at 7:52 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Secure Session Module Options by Default
https://wiki.php.net/rfc/secure-session-options-by-defaultuse_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
Hi Stas,
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
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
On Sun, Feb 2, 2014 at 4:14 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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
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
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, sosession_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
Hi Stas,
On Sun, Feb 2, 2014 at 7:25 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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? Wouldsession_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, sosession_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
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
Hi Stas,
On Mon, Feb 3, 2014 at 5:23 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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
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
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.
Yes.
Session module requires valid entropy source to generate session ID.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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
Hi all,
Secure Session Module Options by Default
https://wiki.php.net/rfc/secure-session-options-by-defaultSession 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
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
Hi all,
Secure Session Module Options by Default
https://wiki.php.net/rfc/secure-session-options-by-defaultSession 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
Hi all,
Secure Session Module Options by Default
https://wiki.php.net/rfc/secure-session-options-by-defaultSession 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