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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
