We often have witnessed situations where someone gets up from their workstation but is not logged off. In such a case, a malicious user can use your workstation to access sensitive data or applications on your computer.
When users leave an open machine with access to critical system components or cardholder data, others may use it in their absence, resulting in unauthorized account access or misuse.
Session timeout is a wise option that should caution in applications. Used to determine how long a device remains authenticated on a switch port before re-authenticating.
PCI DSS requirement 8.1.8 requires the user to re-authenticate to reactivate the terminal or session if a session has been idle for more than 15 minutes. The PCI DSS inactive session timeout requirement applies to administrative or internal accounts.
All accounts with administrative capabilities, including point-of-sale accounts, as well as any accounts used to view or access cardholder data or access systems containing cardholder data, are subject to the PCI session timeout requirement. It also applies to firewalls, routers, networking hardware, and other equipment in your environment.
It should be noted that this does not necessarily indicate that the session has been terminated but rather that the user must re-authenticate to access this session. For example, your screen saver must be enabled from an operating system perspective, and you need to re-authenticate after your screen saver kicks in.
What is Session Timeout?
A session timeout represents an event when a user does not take any action on a website during an interval defined by a web server. On the server-side, the event changes the state of the user session to “invalid,” i.e., “no longer used,” and instructs the webserver to destroy the session by deleting all the data it contains.
For applications with security or privacy concerns, you should automatically log users out after a certain period of inactivity when a session timeout occurs. As session timeout approaches, present a warning to users and allow them to stay logged in. Confirmation is handy in the case of multi-step tasks such as payment, where user tasks will take some time and possible loss of data.
When session timeout occurs, the following are relatively common:
- Users are directed to the Login page with a message that the session has timed out or been suspended, and they must log in to start a new session. This approach is practical when the data on the screen is sensitive.
- Users are kept on the same page, and a pop-up window informs them that their session has been suspended and their data has been saved. This approach is not recommended when the information on the screen is personal or sensitive.
In some applications, sessions may end if the browser window used to access the application is closed.
What Security Risks Does Session Timeout Prevent?
Securing authentication and session management is a broad and complex security area, but protecting the user’s identity and trust is essential. Therefore, always follow good practices to protect the identity of your users, including their passwords and session IDs.
Long or nonexistent timeouts make sessions available to non-users again. For example, users on a public computer may close the browser, thinking it will automatically log them out. Still, an attacker can reopen the browser and re-enter the same session after a while.
In another scenario, the user may actually “log out,” but the session ID remains, allowing an attacker with access to the identity to re-enter the session without re-authentication.
A security best practice with user sessions is to shorten the session timeout as much as possible to minimize the opportunity for an attacker to gain access to your account. In addition to reducing session durations, you can further strengthen security with the option to force a session to end after a certain period of user inactivity.
After a set idle time, users are asked to confirm if they are still using their accounts. If they don’t respond, they should automatically log out of the app. This guards against attackers accessing your system through a logged-in machine that is left unattended for only a few minutes.
What Impact Does Session Timeout Have on Security and Best Practices?
A session timeout defines an action window duration for a user; this window represents the period an attacker can try to steal and exploit an existing user session.
Here are the best practices for session timeout:
- Set the session timeout to the lowest possible value depending on the application’s content.
- Avoid “infinite” session timeouts.
- Prefer the declarative definition of session timeout to enforce a global timeout for all application sessions.
- Monitor session creation and destruction to analyze creation trends and detect an average number of session creations.
So-called TCP/IP hijacking attacks most commonly occur during telnet and Web sessions where security is lacking or lacking and when session timeouts are misconfigured. Similarly, session hijacking can occur if a session timeout is set to a long period of time, allowing an attacker to hijack a session.
Usage Policies and Auto Disconnect
Remote access technologies are a constant source of risk to critical resources and cardholder data. Therefore, PCI DSS requirement 12.3.8 requires your usage policies to include automatic disconnection of sessions for remote access technologies after a specified period of inactivity.
PCI DSS requirement 8.1.8 requires the session to time out after 15 minutes when a user moves away from an open machine with access to critical system components or cardholder data. Similarly, PCI DSS requirement 12.3.8 requires you to minimize the risk of malicious access by adding an auto-disconnect rule for remote access technologies to your usage policies.
PCI DSS requirement 12.3.8 requires you to disconnect sessions after a specified period of time automatically. In PCI DSS requirement 8, we mentioned a session timeout of 15 minutes, but in PCI Requirement 12.3.
Insufficient Session Expiration is a vulnerability that allows an application to reuse old session credentials or session IDs, exposing an application to attacks that steal or reuse users’ session identifiers.
Insufficient Session Expiration can occur when:
- If the timeout is too long or the session is not terminated correctly after using the logout feature. With insufficient session expiration, it can also allow an attacker to use the browser’s back button to web pages previously accessed by the victim.
- A long expiration time increases the chances of an attacker successfully guessing a valid session ID. The longer the expiration period, the more simultaneous open sessions there will be at any given time.
- The larger the session pool, the more likely an attacker can guess a random person. While a short session inactivity timeout does not help if a token is used immediately, a short timeout helps ensure that it is more difficult to catch while still valid.
A web application should invalidate a session after a predefined idle time has passed and provided users with session invalidation tools. These simple measures help keep the lifetime of a session ID as short as possible.
To protect against Insufficient Session Expiration attacks, the logout functionality must be prominently visible to the user, explicitly invalidate a user’s session, and not allow session token reuse.
For detailed information, you can review OWASP’s documentation on session management: