On 8/16/16 10:51 AM, Lester Caine wrote:
On 16/08/16 13:08, Tom Worster wrote:
The default 128 bits Session ID is large enough to ignore collisions
https://wiki.php.net/rfc/session-create-id#discussions
It describes for an application, but PHP is a platform.
There are millions PHP apps or more
Le 10/08/2016 à 11:14, Yasuo Ohgaki a écrit :
Hi all,
This is RFC for adding session_create_id() function.
Hi again,
Not that many of us at AFUP discussed about this RFC (maybe it's because
of the summer and holidays, or it's because not many of us need this?),
but those who did all agree h
Hi Lester,
On Tue, Aug 16, 2016 at 11:51 PM, Lester Caine wrote:
> On 16/08/16 13:08, Tom Worster wrote:
>>> >The default 128 bits Session ID is large enough to ignore collisions
>>> >https://wiki.php.net/rfc/session-create-id#discussions
>>> >
>>> >It describes for an application, but PHP is a p
Hi Tom,
On Tue, Aug 16, 2016 at 9:08 PM, Tom Worster wrote:
>>> I strongly disagree with this kind of attitude.
>>>
>>> If there are users who really do not want collision detection at all,
>>> they should do it by their own responsibility and risk.
>>
>>Above discussion is added to the RFC.
>>
>
On 16/08/16 13:08, Tom Worster wrote:
>> >The default 128 bits Session ID is large enough to ignore collisions
>> >https://wiki.php.net/rfc/session-create-id#discussions
>> >
>> >It describes for an application, but PHP is a platform.
>> >There are millions PHP apps or more and there could be billi
On 8/15/16, 5:39 PM, "Yasuo Ohgaki" wrote:
>On Tue, Aug 16, 2016 at 6:03 AM, Yasuo Ohgaki wrote:
>> On Tue, Aug 16, 2016 at 5:21 AM, Tom Worster wrote:
>>> On 8/14/16 4:13 PM, Yasuo Ohgaki wrote:
>>>
"Now assume a 128 bit session identifier that provides 64 bits of
entropy.
>>>
>>>
>>
On Tue, Aug 16, 2016 at 6:39 AM, Yasuo Ohgaki wrote:
> Do you still sure "There will be no collisions at all"?
Do you still think it's sure "There will be no collisions at all"?
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
On Tue, Aug 16, 2016 at 6:03 AM, Yasuo Ohgaki wrote:
> On Tue, Aug 16, 2016 at 5:21 AM, Tom Worster wrote:
>> On 8/14/16 4:13 PM, Yasuo Ohgaki wrote:
>>
>>> "Now assume a 128 bit session identifier that provides 64 bits of
>>> entropy.
>>
>>
>> What exactly does this mean?
>
> When you have rando
On Tue, Aug 16, 2016 at 5:21 AM, Tom Worster wrote:
> On 8/14/16 4:13 PM, Yasuo Ohgaki wrote:
>
>> "Now assume a 128 bit session identifier that provides 64 bits of
>> entropy.
>
>
> What exactly does this mean?
When you have random 128 bits value, it does not mean it has full size entropy.
Anyw
On 8/14/16 4:13 PM, Yasuo Ohgaki wrote:
"Now assume a 128 bit session identifier that provides 64 bits of
entropy.
What exactly does this mean?
If it means that an attacker knows how to eliminate 2^128 - 2^64
impossible SID values from a search then that SID generation is
insecure, dangerou
Hi all,
"The default 128 bits Session ID is large enough to ignore collisions"
discussion is added for new readers and people couldn't follow
discussion in ML threads.
https://wiki.php.net/rfc/session-create-id#discussions
For the record, when session module was implemented, the way it is now
is
On Mon, Aug 15, 2016 at 5:13 AM, Yasuo Ohgaki wrote:
> Let me paraphrase OWASP's document to show why.
>
> "Now assume a 128 bit session identifier that provides 64 bits of
> entropy. With a very large web site, legitimate users might creates
> 10,000 new session ID per second (New and regenerated
Hi all,
It seems importance of session ID validation that prevents collisions
is not recognized enough.
Brute force session ID hihack risk is described here.
https://www.owasp.org/index.php/Insufficient_Session-ID_Length
The expected number of seconds required to guess a valid session
identifier
Hi Lester,
On Sun, Aug 14, 2016 at 5:35 PM, Lester Caine wrote:
> On 14/08/16 01:56, Yasuo Ohgaki wrote:
>> IMO. PHP should be easiest, yet secure, Web application programming language.
>> I don't see any benefits, but only drawbacks, forcing users "to know session
>> management details to write
On 14/08/16 01:56, Yasuo Ohgaki wrote:
> IMO. PHP should be easiest, yet secure, Web application programming language.
> I don't see any benefits, but only drawbacks, forcing users "to know session
> management details to write secure code" while it is very easy to implement
> tham in Session modul
Hi Tom,
On Sun, Aug 14, 2016 at 12:22 AM, Tom Worster wrote:
> On 8/12/16, 4:38 PM, "Yasuo Ohgaki" wrote:
>
>>Base 64 adds padding for extra bytes. The Padding char is "=" and it's
>>illegal char as SID. Therefore trims is mandatory.
>
> substr(base64_encode(random_bytes($n)), 0, $n). There is n
Hi Yasu,
On 8/12/16, 4:38 PM, "Yasuo Ohgaki" wrote:
>Base 64 adds padding for extra bytes. The Padding char is "=" and it's
>illegal char as SID. Therefore trims is mandatory.
substr(base64_encode(random_bytes($n)), 0, $n). There is no "=" in the
value for any $n.
>Don't you think it's nice t
Hi Tom,
On Sat, Aug 13, 2016 at 3:11 AM, Tom Worster wrote:
> On 8/11/16 6:58 PM, Yasuo Ohgaki wrote:
>>
>> Hi Leigh,
>>
>> On Fri, Aug 12, 2016 at 3:25 AM, Leigh wrote:
>>>
>>> On Wed, 10 Aug 2016 at 10:15 Yasuo Ohgaki wrote:
Hi all,
This is RFC for adding session_crea
On 8/11/16 6:58 PM, Yasuo Ohgaki wrote:
Hi Leigh,
On Fri, Aug 12, 2016 at 3:25 AM, Leigh wrote:
On Wed, 10 Aug 2016 at 10:15 Yasuo Ohgaki wrote:
Hi all,
This is RFC for adding session_create_id() function.
Session ID string uses special binary to string conversion. Users
should write leng
On 12/08/16 10:22, Yasuo Ohgaki wrote:
> Hi Lester,
>
> On Fri, Aug 12, 2016 at 6:12 PM, Lester Caine wrote:
>> On 12/08/16 09:23, Yasuo Ohgaki wrote:
>>> I don't think it's framework job to do.
>>
>> This was a little 'tongue in cheek' ... my main thought was simply that
>> you need a variable '
Hi Lester,
On Fri, Aug 12, 2016 at 6:12 PM, Lester Caine wrote:
> On 12/08/16 09:23, Yasuo Ohgaki wrote:
>> I don't think it's framework job to do.
>
> This was a little 'tongue in cheek' ... my main thought was simply that
> you need a variable 'session_id' and other processes may benefit from a
On 12/08/16 09:23, Yasuo Ohgaki wrote:
> I don't think it's framework job to do.
This was a little 'tongue in cheek' ... my main thought was simply that
you need a variable 'session_id' and other processes may benefit from a
similarly constrained variable, so an intelligent variable could be
envis
Hi Lester,
On Fri, Aug 12, 2016 at 5:01 PM, Lester Caine wrote:
> On 12/08/16 00:20, Yasuo Ohgaki wrote:
>> I've missed to handle session.hash_bits_per_character here. There are
>> people validating SID (used chars and length) via WAF or PHP code.
>> session.hash_bits_per_character handling is ma
On 12/08/16 00:20, Yasuo Ohgaki wrote:
> I've missed to handle session.hash_bits_per_character here. There are
> people validating SID (used chars and length) via WAF or PHP code.
> session.hash_bits_per_character handling is mandatory for such system.
Since 'id' is a variable, isn't this just a s
Hi Leigh,
On Fri, Aug 12, 2016 at 8:07 AM, Yasuo Ohgaki wrote:
> $encoded = base64_encode(ini_get('session.sid_length')*2);
> // Use same charset as PHP
> $sid = substr(rtrim(strtr($encoded, '+/', ',-'), '='), 0,
> ini_get('session.sid_length');
I've missed
Hi Leigh,
One more additional info.
On Fri, Aug 12, 2016 at 7:58 AM, Yasuo Ohgaki wrote:
> IMHO, mandatory API should be in PHP even if it's easy to implement
> and basic API should be in PHP unless it is too easy to be implemented
> userland.
Session SID validation function should be mandatory
On Fri, Aug 12, 2016 at 7:58 AM, Yasuo Ohgaki wrote:
> if sid is not there
s/if sid is not there/if sid is there/
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Leigh,
On Fri, Aug 12, 2016 at 3:25 AM, Leigh wrote:
> On Wed, 10 Aug 2016 at 10:15 Yasuo Ohgaki wrote:
>>
>> Hi all,
>>
>> This is RFC for adding session_create_id() function.
>>
>> Session ID string uses special binary to string conversion. Users
>> should write lengthy and slow code to hav
On Wed, 10 Aug 2016 at 10:15 Yasuo Ohgaki wrote:
> Hi all,
>
> This is RFC for adding session_create_id() function.
>
> Session ID string uses special binary to string conversion. Users
> should write lengthy and slow code to have the same session ID string
> as session module does.
I disagree,
Hi all,
On Wed, Aug 10, 2016 at 7:03 PM, Yasuo Ohgaki wrote:
> It requires a lot less user code
>
> session_rengenerate_id('myprefix-');
>
> yet it is safe.
I forgot to mention important requirement.
It is safe when 'session.use_strict_mode=1'.
Unfortunately, RFC for enabling use_strict_mode by
Hi Marco,
On Wed, Aug 10, 2016 at 6:31 PM, Marco Pivetta wrote:
> The RFC mentions "Without session_create_id(), user has to implement their
> own bin_to_readable() in user land.".
> This pretty much makes it clear that a userland implementation is feasible,
> and thus it should indeed be impleme
Hello,
The RFC mentions "Without session_create_id(), user has to implement their
own bin_to_readable() in user land.".
This pretty much makes it clear that a userland implementation is feasible,
and thus it should indeed be implemented in userland when possible.
That's my reasoning for voting "n
Hi all,
This is RFC for adding session_create_id() function.
Session ID string uses special binary to string conversion. Users
should write lengthy and slow code to have the same session ID string
as session module does. It also validates and makes sure generated
session ID string has no collisio
33 matches
Mail list logo