rfc:precise_session_management

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:precise_session_management [2016/01/31 01:34] – yohgakirfc:precise_session_management [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 5: Line 5:
   * Date Updated: 2016-01-29   * Date Updated: 2016-01-29
   * Author: Yasuo Ohgaki <yohgaki@php.net>   * Author: Yasuo Ohgaki <yohgaki@php.net>
-  * Status: Under Discussion+  * Status: Declined 
   * First Published at: http://wiki.php.net/rfc/session_regenerate_id   * First Published at: http://wiki.php.net/rfc/session_regenerate_id
   * Renamed: https://wiki.php.net/rfc/precise_session_management   * Renamed: https://wiki.php.net/rfc/precise_session_management
Line 117: Line 117:
 When session_regenerate_id(TRUE) (remove old session data immediately) is called, it causes problems like above bug reports. When session_regenerate_id(FALSE) is called, it causes problems such as keep using old session ID, session abuse being undetectable.  When session_regenerate_id(TRUE) (remove old session data immediately) is called, it causes problems like above bug reports. When session_regenerate_id(FALSE) is called, it causes problems such as keep using old session ID, session abuse being undetectable. 
  
-==== Note about session.lazy_write=1 ==== 
  
-session.lazy_write is enabled by default without this RFC. Enabling it is important for session stability. session.lazy_write=1 enables "updated session wins", while session.lazy_write=0 enables "the last session accessed wins". When there are concurrent access to session, "updated session" may be lost due to race condition with session.lazy_write=0. Therefore, session.lazy_write=1 must be set for stable session management. 
  
  
Line 257: Line 255:
 Shorter is better for stolen session abuse mitigation. However, many apps rely on "fixed session ID". Therefore, the default is set to rather long period. 18 hours is probably good enough for daily use. Shorter is better for stolen session abuse mitigation. However, many apps rely on "fixed session ID". Therefore, the default is set to rather long period. 18 hours is probably good enough for daily use.
  
-=== Why this is secure than now ===+OWASP Mobile Top 10 recommends, 
 + 
 +> Good timeout periods vary widely according to the sensitivity of the app, one's own risk profile, etc., but some good guidelines are: 
 +>  
 +>     15 minutes for high security applications 
 +>     30 minutes for medium security applications 
 +>     1 hour for low security applications 
 + 
 + 
 +https://www.owasp.org/index.php/Mobile_Top_10_2014-M9#Lack_of_Adequate_Timeout_Protection 
 + 
 +=== Why this is more secure than now ===
  
 Currently, users must call session_regenerate_id(FALSE) to have relatively stable session. Therefore, old session data is valid as long as it is accessed even if it should be discarded as invalid session. Attackers can take advantage of this behavior to keep stolen session forever, disabling GC by periodic access to stolen session. Currently, users must call session_regenerate_id(FALSE) to have relatively stable session. Therefore, old session data is valid as long as it is accessed even if it should be discarded as invalid session. Attackers can take advantage of this behavior to keep stolen session forever, disabling GC by periodic access to stolen session.
Line 278: Line 287:
  
 <code php> <code php>
-bool session_gc([bool $immediate=FALSE]) +bool session_destroy([bool $immediate_removal=FALSE]) 
 </code> </code>
  
Line 284: Line 293:
  
 Returns session internal data array for session management. Returns session internal data array for session management.
 +
 +<code php>
 +array session_info(void) 
 +</code>
  
 Example return value. Example return value.
Line 396: Line 409:
 Such case may cause inconsistent session state because client will update old session until it gets new session ID.  Such case may cause inconsistent session state because client will update old session until it gets new session ID. 
  
-Currently there is no feasible way that synchronizes server and client data. session.lazy_write=1 mitigates consequences that may result in inconsistent session state, but it is not perfect. To fix this issue, both server and client must have synchronization mechanism like distributed transaction. i.e. Reliable lock/transaction mechanism for both server and client. Without it, PHP has to rely on "eventually consistent" session management and this RFC does it as much as possible.+Currently there is no feasible way that synchronizes server and client data. To fix this issue, both server and client must have synchronization mechanism like distributed transaction. i.e. Reliable lock/transaction mechanism for both server and client. Without it, PHP has to rely on "eventually consistent" session management and this RFC does it as much as possible.
  
  
Line 410: Line 423:
 ===== Vote ===== ===== Vote =====
  
-Requires 50%+ vote is required.+Requires 2/3 vote is required. Current RFC process does not require 2/3 vote to pass. If there are solid and reasonable oppositions, it should be take into consideration to improve RFC/implementation. Please disclose the reason why if you oppose this RFC. 
 + 
 +Vote starts 2016-03-09-09:00(UTC) and ends 2016-03-23-09:00(UTC)
  
 <doodle title="Precise Session Data Management" auth="yohgaki" voteType="single" closed="true"> <doodle title="Precise Session Data Management" auth="yohgaki" voteType="single" closed="true">
rfc/precise_session_management.1454204045.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools