Hi all,
Due to a defect in the RFC, vote is reopened for a week. Removed lines
are indicated by <del></del>. No additional lines nor modifications
other than removed lines for session.use_strict_mode change.
Sorry for the confusion!
============
Currently session module uses obsolete MD5 for session ID. With
CSPRNG, hashing is redundant and needless. It adds hash module
dependency and inefficient (There is no reason to use hash for CSPRNG
generated bytes).
This proposal cleans up session code by removing hash.
https://wiki.php.net/rfc/session-id-without-hashing
I set vote requires 2/3 support.
Please describe the reason why when you against this RFC. Reasons are
important for improvements!
Thank you!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo,
It didn't actually reopen, and just setting closed to false, it kept the
original votes. So I added a second vote below. Bonus: the original is also
preserved.
Hope that's OK.
- Davey
Hi all,
Due to a defect in the RFC, vote is reopened for a week. Removed lines
are indicated by <del></del>. No additional lines nor modifications
other than removed lines for session.use_strict_mode change.
Sorry for the confusion!============
Currently session module uses obsolete MD5 for session ID. With
CSPRNG, hashing is redundant and needless. It adds hash module
dependency and inefficient (There is no reason to use hash for CSPRNG
generated bytes).This proposal cleans up session code by removing hash.
https://wiki.php.net/rfc/session-id-without-hashing
I set vote requires 2/3 support.
Please describe the reason why when you against this RFC. Reasons are
important for improvements!Thank you!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Davey,
It didn't actually reopen, and just setting closed to false, it kept the
original votes. So I added a second vote below. Bonus: the original is also
preserved.Hope that's OK.
Oops, I thought flip-flopped the switch. Thanks you but wouldn't it
easier with single vote entry?
If you don't mind, I would like to have single vote section because
this is reopen for a RFC defect.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Done, I guess it just needed a unique name, removing the first one kept the
new one only :)
- Davey
Hi Davey,
It didn't actually reopen, and just setting closed to false, it kept the
original votes. So I added a second vote below. Bonus: the original is
also
preserved.Hope that's OK.
Oops, I thought flip-flopped the switch. Thanks you but wouldn't it
easier with single vote entry?
If you don't mind, I would like to have single vote section because
this is reopen for a RFC defect.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
Old votes are removed. Everyone already have voted 1st vote should vote again!
https://wiki.php.net/rfc/session-id-without-hashing#vote
Sorry for the inconvenience & thank you for voting!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
Due to a defect in the RFC, vote is reopened for a week. Removed lines
are indicated by <del></del>. No additional lines nor modifications
other than removed lines for session.use_strict_mode change.
Sorry for the confusion!============
Currently session module uses obsolete MD5 for session ID. With
CSPRNG, hashing is redundant and needless. It adds hash module
dependency and inefficient (There is no reason to use hash for CSPRNG
generated bytes).This proposal cleans up session code by removing hash.
https://wiki.php.net/rfc/session-id-without-hashing
I set vote requires 2/3 support.
Please describe the reason why when you against this RFC. Reasons are
important for improvements!Thank you!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Just wanted to let you know I voted no because of the BC breaking change to
the INI options that could easily break many custom session handlers — any
session handler that stores the sessions in a fixed-width column will be
broken.
I'm fine changing the defaults in the php.ini-*, but not changing the
defaults in the code. Also, documenting the better values as recommended.
Putting my RM hat on, I'm not comfortable merging this in 7.1 with an
unnecessary BC breaking change. Changing the default is the BC break,
regardless of the ability to change the settings back to the previous
values.
Hi all,
Due to a defect in the RFC, vote is reopened for a week. Removed lines
are indicated by <del></del>. No additional lines nor modifications
other than removed lines for session.use_strict_mode change.
Sorry for the confusion!============
Currently session module uses obsolete MD5 for session ID. With
CSPRNG, hashing is redundant and needless. It adds hash module
dependency and inefficient (There is no reason to use hash for CSPRNG
generated bytes).This proposal cleans up session code by removing hash.
https://wiki.php.net/rfc/session-id-without-hashing
I set vote requires 2/3 support.
Please describe the reason why when you against this RFC. Reasons are
important for improvements!Thank you!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Davey,
Just wanted to let you know I voted no because of the BC breaking change to
the INI options that could easily break many custom session handlers — any
session handler that stores the sessions in a fixed-width column will be
broken.I'm fine changing the defaults in the php.ini-*, but not changing the
defaults in the code. Also, documenting the better values as recommended.Putting my RM hat on, I'm not comfortable merging this in 7.1 with an
unnecessary BC breaking change. Changing the default is the BC break,
regardless of the ability to change the settings back to the previous
values.
Fair discussion. I can understand very well.
The reason why I would like to increase number of bits in session ID is this.
https://www.owasp.org/index.php/Insufficient_Session-ID_Length
It suggests at least 128 bits session ID that includes at least 64 bits entropy.
We may assume very good entropy for current MD5 style session ID
string (128 bits) with CSPRNG. It's not safe to assume fully random
bytes, let's assume 80 bits entropy. 80 bits entropy is strong
enough for most sites, but there were concerns about quality of PRNG
during discussion.
80 bits entropy for MD5 style session ID string and a web site
- Allows 1K reqs/sec
- 10M active sessions in system
It requires 1916739 years to guess a session ID on average.
Now, let assume bad PRNG only generates only 48 bits entropy for MD5
style session ID string and a web site
- Allows 1K reqs/sec
- 10M active sessions in system
It requires 14073 seconds to guess a session ID on average.
NOTE: If PRNG is bad like this, current way will results in the same
bad situation or worse. The proposed way is better.
Personally, I don't think any PRNG claims as CSPRNG would not generate
such bad random bytes, but the default is extended to 240 bits session
ID string for this reason. It should be very strong even with poor
PRNG and good enough for billions of active sessions and tens of
thousands guesses per/second.
I don't mind pausing vote to have consensus on how many bits for
session ID string is preferred.
Regards,
YFI. Current session module has collision detection when proper API is
implemented. Therefore, there is no chance a user gets a session ID
owned by someone else.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
I would like to ask the default session ID string preference.
Details of guessing an active session ID is described in previous mail.
Please refer it for details.
I don't mind pausing vote to have consensus on how many bits for
session ID string is preferred.
Current default is 128 bits with 32 chars. (Hex string which has 4
bits per char)
Pros: Compatible with current default.
Cons: Weaker than proposed default
Proposed default is 240 bits with 48 chars. (Special form which has 5
bits per char)
Pros: Stronger than current default.
Cons: Incompatible with current default.
128 bits would be strong enough with CSPRNG, while 240 bits would be
preferred as precaution.
Which default would you prefer?
I would like to restart vote based on the result.
Thank you!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
My suggestion:
Re-start the vote, three options:
Yes, new defaults (BC Break), Yes, old defaults (no BC break), No
OR:
add a second vote to the page, with:
Use new defaults (BC Break), Use Old Defaults (No BC Break)
Hi all,
I would like to ask the default session ID string preference.
Details of guessing an active session ID is described in previous mail.
Please refer it for details.I don't mind pausing vote to have consensus on how many bits for
session ID string is preferred.Current default is 128 bits with 32 chars. (Hex string which has 4
bits per char)
Pros: Compatible with current default.
Cons: Weaker than proposed defaultProposed default is 240 bits with 48 chars. (Special form which has 5
bits per char)
Pros: Stronger than current default.
Cons: Incompatible with current default.128 bits would be strong enough with CSPRNG, while 240 bits would be
preferred as precaution.
Which default would you prefer?I would like to restart vote based on the result.
Thank you!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Davey,
My suggestion:
Re-start the vote, three options:
Yes, new defaults (BC Break), Yes, old defaults (no BC break), No
OR:
add a second vote to the page, with:
Use new defaults (BC Break), Use Old Defaults (No BC Break)
Sounds good to me.
I'll use 2nd option and restart.
Thanks
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Davey,
My suggestion:
Re-start the vote, three options:
Yes, new defaults (BC Break), Yes, old defaults (no BC break), No
OR:
add a second vote to the page, with:
Use new defaults (BC Break), Use Old Defaults (No BC Break)
Sounds good to me.
I'll use 2nd option and restart.
I've updated the RFC.
https://wiki.php.net/rfc/session-id-without-hashing
I've set new vote end date to 2016/08/02 23:59:59.
Could you check if the RFC is OK? If it's OK, I'll create a new thread
for vote notice.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Looks good to me, go for it :)
Thanks,
- Davey
Hi Davey,
My suggestion:
Re-start the vote, three options:
Yes, new defaults (BC Break), Yes, old defaults (no BC break), No
OR:
add a second vote to the page, with:
Use new defaults (BC Break), Use Old Defaults (No BC Break)
Sounds good to me.
I'll use 2nd option and restart.I've updated the RFC.
https://wiki.php.net/rfc/session-id-without-hashing
I've set new vote end date to 2016/08/02 23:59:59.Could you check if the RFC is OK? If it's OK, I'll create a new thread
for vote notice.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Davey,
Looks good to me, go for it :)
Done.
Thank you for helping!
--
Yasuo Ohgaki
yohgaki@ohgaki.net