[RFC][VOTE] Add session_create_id() function

Hi all,

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 default
https://wiki.php.net/rfc/session-use-strict-mode
is declined.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

if sid is not there

s/if sid is not there/if sid is there/

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hi Leigh,

One more additional info.

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 for user defined
save handlers. Unless we have ready to use session_create_id(), they
have to implement by themselves. Requiring something like

function session_create_id(string $prefix)
{
$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');

$sid .= $prefix;

// Now validate SID so that it does not have collisions
when session is active, connect to database and validate SID
  try to fetch sid
    if sid is there
      try again to generate SID few times
  if SID validation failed
     fatal error
  return safe SID

when session is inactive
return unvalidated SID
}

is not good API design, IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hi Leigh,

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, this pretty much covers it:

function session_create_id()
{
$encoded = base64_encode(random_bytes(random_bytes(32)));
// Use same charset as PHP
return rtrim(strtr($encoded, '+/', ',-'), '=');
}

Thank you for insight!

You've missed to set SID to proper length and SID validation.

Replacing rtrim() with substr() is fixes that.

function session_create_id(string $prefix)
{
$encoded = base64_encode(ini_get('session.sid_length')*2);

Did you omit random_bytes() in this line?

// Use same charset as PHP
$sid = substr(rtrim(strtr($encoded, '+/', ',-'), '='), 0,
                      ini_get('session.sid_length');

$sid .= $prefix;

// Now validate SID so that it does not have collisions
when session is active, connect to database and validate SID
  try to fetch sid
    if sid is not there
      try again to generate SID few times
  if SID validation failed
     fatal error
  return safe SID

when session is inactive
return unvalidated SID
}

This is what proposed session_create_id() does.
I used pseudo, but it should be easy to imagine it would be lengthy code.

You don't need to waste time checking for collisions if the SID has a
random component of sufficient length. 32 random base-64 characters is
sufficient.

There are lots of purposes for random strings with negligible chance of
collision. Hence some frameworks provide the function, e.g.
http://www.yiiframework.com/doc-2.0/yii-base-security.html#generateRandomString()-detail

Only the search of the the session database for collisions seems hard to
me. But I don't understand why it is needed.

Tom

Hi Tom,

Rather than argue the details of randomness, I have more basic comments.

1. If an app needs to access session values, it can and should do this
   without indirection through the PHP session ID table.

I don't get point. Why?

1. It is not necessary. An app can instead store session-related data in
   a DB that provides lookup and/or search on the session data itself
   rather than the PHP session key. Lester Caine described this.

2. Searching PHP's session database is nasty. It's low-level and the app
   has to understand the handler. But I want apps to work independent of
   sessions being in memcache to Redis or Galera or whatever. Depending on
   handler, it can involve a scan which is slow. And it's hard to make the
   overall operation that uses session table lookup transnational. And the
   session store may be distributed example below(*).

So it's nasty and unnecessary. Instead, the app can and should
implement the business logic to be entirely above and ignorant of PHP
session mechanics.

2. Users should generally let PHP choose random IDs.

I agree.

3. If PHP is to allow a user to chose its own session IDs, avoiding
   collision is should that user's responsibility.

No. I've already explained why this is difficult.

It is easy if you choose to avoid rather than detect. Use a
random component long enough for your needs. In other words, I disagree
with the sentence in your RFC:

Something like above code is required to implement recommended user
session save handlers currently.

It is not needed because if 64^32 SID values is inadequate for your app
then you may increase session.sid_length.

Please read previous mail.
Or try to write session save handler that detects collisions with
memcached, then you'll see why.

I understand your point. At the same time I see no need for collision
detection.

Questions: When I get a value from session_create_id(), what kind of
guarantee comes with it? Is the ID reserved for me? If so, for how long?

4. Generating unique unpredictable IDs (without requiring collision
   detection) is a common problem with known and trusted solutions.

I agree. It's common because many unique ID generator do not have
centralized database to avoid collisions. In contract, session has
centralized database and it's just a matter of one lookup. (Therefore,
session module should lookup database)

(*)Some session stores are federated, e.g. a cluster of 3 hosts each
with a memcached server and each with PHP configured with session
redundancy to save two copies.

While session_create_id() could potentially use the same hashes that
memcache/d extensions uses to associate SIDs with memcached servers, the
app has to search them to find the entry with a given SID prefix.

Regards,

P.S. I'll add optimization that eliminates SID validation lookup for
normal operations. You don't have to worry about session performance
if I add this.

--
Yasuo Ohgaki
yohgaki@ohgaki.net