OWASP Session Management Cheat Sheet (https://www.owasp.org/index.php/Session_Management_Cheat_Sheet) recommends to implement an absolute session timeout (in addition to idle session timeout). It means that the application forces user to re-authenticate regardless of session activity.

Is there any recommendations for the duration of that timeout to be secure enough and not annoy end users? Would it be enough to set an absolute session timeout to 24 hours? more?

The application I'm working on will be placed within internal corporate network and is used by users to perform their every day job responisbilites so frequest re-authentication request can be a usability issue.

  • I don't know of any advice on this but I find that logging in once a day is not too much of a hassle. Commented Nov 29, 2015 at 21:50

2 Answers 2


There is no strict answer to the time length. The limits of idle timeouts depend on regulations and possibly jurisdictional laws.

Session-based access to cardholder data in PCI DSS 3.1 is required to be "reasonable". PCI DSS 3.1 in item 8.1.8 provides specific guidance on this

8.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.

SOURCE: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

Similar suggestions exist for other compliance programs. Making it configurable and flexible according to data sensitivity context is likely your best bet.

Absolute timeouts aren't mandated under any framework I know of, but they do seem interesting. The user experience impact is potentially significant, but the benefit of limiting the duration of a session hijacking is also significant. 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.

I recommend pursuing a Renewal Timeout if the application permits it and using a renewal timeout no greater than 1 hour. 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.

If Absolute Timeout is your only option I would make the timeout 24 hours. It's a sensible limit and limits surprise. A multi-day absolute timeout would likely confuse users as they'd see the re-prompt as arbitrary or potentially indicative of application failure.

  • 1
    For PCI this should usually be 15 minutes (8.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.). Commented Dec 2, 2015 at 9:00
  • @SilverlightFox good catch. Noted and linked to PCI DSS 3.0 doc. I couldn't find that quickly because I was looking for timeout and time out and not session. I was pretty sure it was 15 minutes, but unable to find the specific reference I punted to a more general recommendation. Commented Dec 2, 2015 at 12:56
  • 1
    Also, the current standard is PCI DSS 3.1. ;-) Commented Dec 2, 2015 at 13:51
  • Note that the question was about absolute timeouts, not idle timeouts. Commented May 16, 2016 at 18:04
  • @CharlesWood touché. I misread the question. I'll revise my answer. Commented May 18, 2016 at 1:41

24 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).

You have to set the divisor for the garbage collection to 1, then it is 100%.


You have to check how sessions and garbage collection work in the serverside language that you use.

When the browser is closed the session is also closed and will be likely deleted from the garbage collection.

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.

But keep in mind that sessions do not automatically end after 24 minutes when the garbage collection does not delete them for sure (the divisor).

You can always resume a session in your code and extend its lifetime when a user is active. If the user is not active for a specific time, let the session expire and delete it.

But a single session should be as short as possible and is meant to expire.


  • 1
    Don't really agree, firstly 24 minutes is far too short for an absolute timeout given the users are already in a relatively secure environment (internal network) and there are productivity considerations, especially if the PCs aren't shared and their PCs lock themselves automatically. For example gmail seems to have a absolute timeout of at least 30 days (at least in my case with 2FA enabled). Secondly, PHP probably isn't the best source for sensible defaults when it comes to security...
    – thexacre
    Commented Nov 29, 2015 at 21:33
  • The GC timeout isn't really relevant here as it is for unused data structures while an absolute session timeout should happen even for active sessions. Commented Nov 29, 2015 at 21:48
  • Right. Sessions can not be stored for days and also should not. If the browser is closed the session is destroyed. What you mean are cookies. Session cookies have a lifetime of 0 which means just as long as the browser is open. Normal cookies have a lifetime. But you asked about sessions. It has nothing to do with PHP but how you store and handle sessions.
    – user6090
    Commented Nov 29, 2015 at 22:17
  • I think you're getting confused between the concept of session management (ie. maintaining server side information about a user which is persisted across requests and associated with a user using a unique identifier in a cookie) and a cookie with an expiry of 0 (commonly called a session cookie). I can understand why you'd be confused because I think PHP uses a cookie with an expiry of 0 by default for the cookie that identifies a server side session. I think he's basically asking when should you expire the server side portion regardless of when the cookie expires.
    – thexacre
    Commented Nov 29, 2015 at 23:38
  • Daniel, I'm not talking about idle session timeout that is obvious, but about absolute session timeout when users can really work with the system, but they are forced to re-authenticate despite their activity.
    – Salamander
    Commented Nov 30, 2015 at 7:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .