Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101640
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <08.38.12394.386F36A5@pb1.pair.com>
To: internals@lists.php.net
Date: Sun, 21 Jan 2018 03:10:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Better Session Management by OTP encryption
From: dominic.guhl@posteo.de (Dominic Guhl)

The PHP documentation on Session Data Deletion:

> Obsolete session data must be inaccessible and deleted. Current
session module does not handle this well.

Hello everyone!

the current implementation of Sessions asks the PHP developer (which I
name as "the user" from now on) to do a lot on his own to secure their
session data, especially if these are overdue. These steps are
timestamps in sessions, locking access to obsolete data, and eventually
to keep track of active sessions.

The cause for this circumstance is the run-per-request nature of PHP;
even if PHP-FPM is running, the nature of PHP does not change.

What if the configured session expiry controls a One-Time Pad encryption
which secures the session data, even over requests?

PHP-FPM hands over a shared secret, which itself is generated each time
once PHP-FPM gets started. With the shared secret, the expiry timeframe
and the system's time, PHP can generate a one-time password which can be
used to encrypt and decrypt the data. Once the expiry timeframe is
reached, PHP generates a new password for the session data encryption -
which, by making the former one unavailable, disables PHP to access the
expired session data.

Would session data need to be accessed for a longer time, the One-Time
Pad algorithm - since it's time-bound - is theoretically able to
generate passwords on the previous (c-1) and the next (c+1) timeframe as
well as on the current (c) one, but no other than the password generated
in c is which the session data would have been encrypted. A shift into
the next time-frame would require a decryption with the password from
c-1 and re-encryption with the password from c.

The Garbage Collector would recognize by the current OTP which session
data can be accessed and which cannot and would be able to detect this
way which data can be wasted. When exactly the GC will get active, would
basically not be relevant anymore, because the Session Manager would not
be able to read the expired data.

Main thing to know: this is all PHP-internal and would not affect the
user. The encryption of session data helps to protect the data between
requests and after expiry as well. If you cross (or HMAC) the One-Time
Password with the session's ID, the session data could be protected on a
session level, too.

Okay, I outlined my idea as I was recommended by "The Mysterious PHP RFC
Process" and as I am new to PHP Core Development, I would like to know
what you think.

Best regards,

Dominic