Session Termination

The Goal

The aim of this knowledge base entry is to give guidance around terminating user sessions within applications, whilst balancing the usability of the system. When we refer to the “user session” we’re referring to how an application remembers that a user is logged in. When we refer to “session termination” we’re referring to the ability for both the system and the user to revoke a previous authenticated session.

Key Takeaways

Understand why sessions should automatically terminate after a period of user inactivity.
Understand why sessions should automatically terminate after a fixed absolute period.
Understand why users should be able to terminate the current session as well as a previously logged in session on devices they may no longer have access to.
Understand the trade off when requiring the user to reauthenticate frequently.

The Trade Off

The main trade off with user session security is balancing user convenience with application security. For example, if the user only had to log in once and then the system remembers their details forever, that would be very convenient for the user – but what if the user logged in on a shared device and forgets to log out? If there is no session timeout on that device, then the session may be compromised by other users of the device who may be able to illegitimately access the affected account.

On the other hand, having the session terminate automatically after a very short period of inactivity can annoy users and, in some cases, can lead to bad security practices, such as the user selecting a weaker, simpler, password – or disabling additional protections such as multifactor authentication – due to the requirement to frequently reauthenticate.

What are we protecting against?

In the most basic sense, we are aiming to establish a session management system that prevents any user from illegitimately accessing another user’s session. There are a couple of ways that this can occur.

Shared devices – a user may log in on a shared device that other people have access to. This may lead to the user’s session being compromised by another user of that system.
Unattended devices – a user may log in on a trusted device but, leave that device unattended whilst visiting the bathroom or attending a meeting, and an opportunistic attacker may access the application in their absence.
Unintentional disclosure – the access token may be disclosed in an unintentional way, such as if a user logs ‘in’ on a device which is later found to have been compromised by malicious software.

Inactivity Timeouts

A user may choose to login to the application on a device regarding which they are not the only user. This could be a device at work, a friend’s device, or a device which they own but choose to sell. In all cases, having a session that never ends is a potential security risk.

Additionally, users may leave their device unattended whilst it is logged into the application, such as whilst visiting the bathroom or to attend meetings.

If the application implemented an “inactivity timeout” where the user’s session becomes invalid after a certain amount of inactivity, then this would limit this potential exposure.

How short the timeout should be is heavily dependent on the criticality of the application – and may take into account the normal usage patterns for the application. For low risk applications this could be 15 – 30 minutes of inactivity. Whereas for high risk applications this should be reduced to 2 – 5 minutes. Alternatively, the application may be configured such that high risk accounts such as administrator accounts (which should only be used for specific administration activities) have a very short timeout. Whereas lower privileged accounts may have a longer timeout. Usage patterns can be taken into account, for example for a low risk application that a user will check throughout the day, setting the timeout to 30 minutes might be desirable to prevent requiring the user to reauthenticate frequently.

Absolute Timeouts

Applications should also implement an absolute timeout on sessions, such that if an account is compromised by an attacker, the window for which they can perform malicious activities is limited. To minimise frustration for the user, this can be based around the normal usage pattern. For example, for a high-risk application that a user is expected to interact with to perform a single task (such as paying a bill online) then the absolute time can be very short, such as 2 hours. Whereas if the user is likely to interact with the application throughout the day, then an absolute timeout of 8 hours likely offers a good balance of security and usability.

Enforcing Session Termination – Logging Off

The application should allow the user to manually terminate their session and this should be enforced on the server. This is key as a user may authenticate on a shared device and may wish to terminate the session once their activities are completed. If the application does not enforce session termination on the server, it may be possible for an attacker to extract the session token from the device and gain unauthorised access to the system. Terminating the session client-side, such as clearing cookies or other client-side session token storage is not sufficient to protect the application.

Enforcing Session Termination – Other Sessions

If a user logs in on a shared device and forgets to terminate their session at the end of their activity, the application should still allow the user to terminate the previous session without requiring access to the original device. For example, if the user logged in on a public access device whilst travelling, or if they logged in on a device which they have subsequently sold, they may not be able to access that device to terminate the session.

This could be done by allowing a user to view a list of all active sessions and allowing the user to select previous sessions for termination. Alternatively, this functionality may be provided by terminating all existing sessions when the user resets their password.

Simultaneous Sessions

In order to prevent some of the risks discussed above (such as a user forgetting to logout of the application on a shared device) some systems prevent multiple simultaneous sessions. However, given that modern users are likely to own multiple devices and are likely to be allowed to access the system from multiple devices (such as their laptop and mobile phone), preventing multiple sessions can be frustrating to users and may cause the user to choose weaker passwords or disable additional authentication methods, if they are required to reauthenticate frequently.

Therefore generally, unless there is a specific risk that the system aims to protect against by preventing multiple sessions, that cannot be mitigated through the steps discussed above, it is not recommended that multiple simultaneous sessions are blocked.

However, in the case that multiple sessions are allowed, the application should allow the user to easily check the details of previous sessions and should allow the user to revoke those sessions. In the case of high-risk applications, consider alerting the user to previous sessions that exist. When presenting information about previous sessions the system should provide enough information to the user to allow them to differentiate sessions – such as providing information like the login date and time and the device type that the login was performed on. This information could be gained from the device’s User Agent.