Have you noticed that Google, Facebook, and Twitter keep you logged in for a very long time? Unlike your bank, they don't automatically log you out after a period of inactivity.
How can they get away with this, and why do your web applications likely still need short session timeouts?
Google, Facebook, and Twitter still have session timeouts, but you don't encounter them very often because sessions timeout every three months or so.
OWASP Session Timeout Recommendations
One of the most authoritative web application security standards organizations is OWASP (Open Web Application Security Project). Here’s what OWASP says about session timeouts: “Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active. The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring...Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.”
From the federal guideline perspective, the draft NIST 800-63B – Digital Identity Guidelines proposes the following recommendation for providing high confidence for authentication: “Reauthentication of the subscriber SHALL be repeated following no more than 30 minutes of user inactivity.”
Session Timeout Considerations
One of my clients recently attempted to justify their 7-day idle timeout by basically saying, "If Facebook, Google, and Twitter don't force you to reauthenticate every 30 minutes, then why should we?"
If you have had similar thoughts, you should consider the following.
First, your organization is not Google, Twitter or Facebook. Your business model is likely not geared toward keeping users engaged with your service for sustained periods of time like these sites are. You have an obligation to evaluate your business' unique operating environment risk, independent of what popular websites are doing.
Second, and most importantly, these sites mitigate the risk of a hijacked session with several security enhancements that your site probably doesn't offer. These features include:
- Remote Logout - Google, Facebook, and Twitter allow you to see a list of devices with active sessions and to terminate any of these sessions. This comes in handy when you realize you forgot to logout of Facebook from your friend's computer, and you don't trust them to not post to your news feed.
- Reauthentication Prompts - If you try to make security-sensitive modifications to your account on Twitter and Google, you may be prompted to reauthenticate first. This will limit the damage that account hijackers can cause.
- Login History - Each service allows you to review the login history in the case you suspect your account may have been compromised. You can use this information to help identify hijacked sessions.
- Notifications - These sites notify you via email when certain sensitive actions are taken on your account. For example, I recently changed my Recovery Email settings in Google, and received an email notification of the change. If an attacker makes modifications to my account on these services, I am likely to be notified so I can take corrective action sooner.
Google, Twitter, and Facebook have made the risk-based decision to implement a suite of detective and corrective security controls for dealing with session hijacking in lieu of implementing the preventative security control of logging out an idle session after a reasonable timeout period. The business risk of pre-emptively logging out a user after a short timeout period for these companies has been evaluated as greater than the business risk of session hijacking threats with these detective and corrective controls in place.
So, unless your web application allows users to review session history, review active sessions, terminate remote sessions, and notify users of security-sensitive changes to their account, you probably need a session timeout that is in line with OWASP and NIST recommendations.
If you are wondering, "How long should our session timeout be?" The answer will depend on your unique environment and risk tolerance. Take the time to analyze the risk for your environment, and don't assume that other organizations' risk decisions cross-apply to you.
Have questions about how session timeouts apply to your unique environment? Feel free to email me. I would love to help out.