SSOCircle

A synonym for “timeout” is “break” or “pause”. Sounds like a good thing – in principle. When it comes to “session timeout” perception might be different. What exactly do we mean with “session timeout”? At OWASP you might find explanations similar to:

Session timeout defines an action window which represents the time span in which an attacker can try to steal and use an existing user session.

For the end user timeouts are just annoying and ideally shouldn’t exist or at least should be “infinite”. Finding a balance between security and usability is a challenge that we already know from authentication by passwords: Password protected applications shouldn’t exist either or the password should be at least simple and easy to remember. That translates to: Short, the same everywhere and intuitive like “password”, “aaaaa” or the name of my dog.

Back to OWASP and their definition about the action window for stealing identities. Session expiration is mandatory unless you want to give an attacker unlimited time to guess or brute-force a valid session token. You definitively need to acknowledge that a session token, for example a cookie, represents your credentials for accessing protected content. During the time of its validity the token is as confidential and worth protecting as username and password itself. This becomes particularly critical if the transport of tokens is in clear, only secured by weak encryption, in shared environments or if you take into account that session tokens can potentially be logged by servers or proxy servers.

Sounds unrealistic? Think of the situation when you go for a meeting and leave you laptop unlocked. Someone can easily access your browser, retrieve cookie information, and go back to his own computer impersonating you. In that case the best prevention would be locking the screen or manually logging out before leaving. But, in the rare case we forgot to lock the screen, an idle timeout would mitigate the risk of cookie theft. If the attacker steals the cookie, say 20 min after you left your desk, an idle timeout of 15 min would have saved you and your data.

If you argue that you don’t need an idle timeout since you can deal with that by reasonable diligence: Remember the Odd Job Trojan in 2011. OddJob infected Firefox and Internet Explorer stealing session identifiers of online banking applications, intercepting manual logout commands from the user, hijacking sessions and keeping them alive by sending periodic requests to the server. Ending up with access to banking account information and transactions for a long time.

Consider weak encryption: The Freak Attack (https://freakattack.com) published on March 3, 2015 allows attackers to intercept HTTPS connections and force the use of export-grade cryptography leaving most Windows, Android, Apple devices and Macs with OS-X vulnerable. And what is the impact to session timeouts? Forcing the use of export-grade crypto means a downgrade in key length to a 512-bit. Nadia Heininger (University of Pennsylvania) was able to factor 512-bit RSA keys in 7.5h on a cluster of EC2 servers for a cost of $104. If your session lasts longer than 7.5h not only the traffic could be decrypted but also your session cookie could be read and USED. An absolute timeout shorter than 7.5h would mitigate the risk to be “freak attacked “.

Coming back to the point: Session expiration should be used to make your systems more secure. More secure, in the context here, means giving the attacker less time to break your safeguards. Please note: Invalidating sessions after timeout or logouts must be done on the client and server side. The latter is the most relevant and mandatory from a security perspective. Removing the session identifier (e.g. cookie) only on the client side is not considered safe.

The safeguards related to session validity are:

Manual session expiration: Provide an easily accessible logout button, so that the user has the ability to logout and end the session whenever his work is finished or paused. Unfortunately nowadays in many social applications the logout button is hidden somewhere to keep the users logged in.
Idle Timeout: Most applications implement idle timeouts which terminate a session after a certain amount of inactivity. The length of an idle timeout heavily depend on the kind of application. According to OWASP common idle timeouts for high-value applications are 2-5 minutes, medium critical applications 15-30 minutes and low risk applications approx. 3 hours.
Absolute Timeout: A timeout after which a session is closed no matter there is user activity or not. The absolute timeout limits the time a hijacked session can be used. Banking and shopping applications typically implement an absolute timeout of 30 – 60 minutes. The absolute timeout heavily depends on application use cases. For some applications a timeout of 8 – 24h does make sense.
Renewal Timeout: Some applications define renewal timeouts, which probably are the most difficult from implementation view point. After the renewal timeout a session identifier is exchanged to a new one, leaving the session itself valid. Technically the renewing of session identifiers limits the time a hijacked session could be used by an attacker without impacting the usability of the normal user as the session remains still valid. But with that approach problems can occur, if the client is still using the old session id when it is already set to invalid. The change of session id can also imply race conditions in which the attacker, not the legitimate user, is able to obtain the new session id.

Some words about session synchronization: In loosely coupled single sign on systems (via SAML, OpenID Connect …) there is no single overarching session. Individual applications create their own local session without revalidating the session on subsequent requests. This constitutes an important difference in behavior from classical web access management systems, which typically maintain a central session and applications verify session validity periodically.

Session expirations, manually or through timeouts, pose challenges to these SSO environments. A manual logout from one system should be propagated to other systems (although there might be good reasons for not doing that). If there is no global logout, the user experience might be a little confusing, since logging off a system might not show the expected effect as you are transparently signed in again through the existing identity provider session – at least if everything is working fine and the session at the identity server is still valid.

And what about timeouts? Does it make sense to propagate idle timeouts? Being idle in one application doesn’t mean you are idle in another application as well. What about idle timeouts at the IDP? Consider the case in which you are surfing one application and then you access another application. If the IDP expired your local session because of inactivity at the IDP, single sign on will not work and users have to reenter their credentials. Is that what you expect from a working SSO system?

SSO integrations are normally more difficult than expected. Session synchronizations are even worse and often do not work in real life deployments. SAML 2.0 specification describes several profiles for single logout. OpenID Connect session management specification is still in draft http://openid.net/specs/openid-connect-session-1_0.html (as of 03/2015). There are some people in the identity community advocating to abandon single logout. Their argument: It is better to know there is no single logout and deal with it (for example by closing the browser window) than relying on a working single logout which in reality might be incomplete or even nonexistent.

Final remark: There is no such thing like a “gold standard” for timeouts. As often in security topics, it is all about risk management. Risk based considerations may help to find a good balance between user experience and security.