Re: [PHP-DEV] Better Session Management by OTP encryption
Hi Dominic, On Sun, Jan 21, 2018 at 11:10 AM, Dominic Guhl wrote: > The PHP documentation on Session Data Deletion: > > > Obsolete session data must be inaccessible and deleted. Current > session module does not handle this well. > Session managers must remove obsolete sessions for security reasons. PHP session module does not handle this well. There was RFC. https://wiki.php.net/rfc/precise_session_management I think those who opposed this RFC does not understand security implications/risks w/o this proposal. This can be done by user code as well. Some of people insisted this kind of feature should be implemented in frameworks even though no frameworks did not implemented it. It's been 5 years since the RFC is created. All of PHP frameworks and apps should have implemented proper session management by now. If not, we are better to implement it in the session module. IMO. Current OWASP session management cheat sheet https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Expiration defines idle/absolute/renewal timeouts. PHP cannot handle any of them properly. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Better Session Management by OTP encryption
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
[PHP-DEV] Better Session Management by OTP encryption
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
