There are clear recommendations in the cheatsheet: Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.īut keep in mind that sessions do not automatically end after 24 minutes when the garbage collection does not delete them for sure (the divisor). When the browser is closed the session is also closed and will be likely deleted from the garbage collection. You have to check how sessions and garbage collection work in the serverside language that you use. You have to set the divisor for the garbage collection to 1, then it is 100%. A multi-day absolute timeout would likely confuse users as they'd see the re-prompt as arbitrary or potentially indicative of application failure.Ģ4 hours is possibly to much, 24 minutes is the default value for PHP sessions (session.gc_maxlifetime) but there is just a probability of 1% that the sessions expire after this time (session.gc_divisor). It's a sensible limit and limits surprise. If Absolute Timeout is your only option I would make the timeout 24 hours. This substantially reduces the hijacking risk and should be practical with any application that has a straight-forward (small and manually copyable) or serializable session state. I recommend pursuing a Renewal Timeout if the application permits it and using a renewal timeout no greater than 1 hour. It seems like a better solution - if you control the application code - would be session rotation (ie: a Renewal Timeout in OWASP parlance) whereby the application generates a fresh session ID periodically. The user experience impact is potentially significant, but the benefit of limiting the duration of a session hijacking is also significant. Making it configurable and flexible according to data sensitivity context is likely your best bet.Ībsolute timeouts aren't mandated under any framework I know of, but they do seem interesting. ![]() Similar suggestions exist for other compliance programs. PCI DSS 3.1 in item 8.1.8 provides specific guidance on thisĨ.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session. Session-based access to cardholder data in PCI DSS 3.1 is required to be "reasonable". The limits of idle timeouts depend on regulations and possibly jurisdictional laws. There is no strict answer to the time length.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |