Because the ways in which application sessions are handled can affect the user experience, it’s important to get it right. You want to keep session data safe from attackers, but you also want to ensure that users enjoy interacting with your applications and aren’t unnecessarily interrupted during their journeys with authentication requests. The more your users enjoy their experiences, the more likely they are to become loyal customers, have stronger emotional connections to your brand, and refer other customers, which will ultimately increase your revenue.
For example, most people understand why financial institutions require
While no solution is perfect and some level of risk will always exist, we’ve created a list of best practice planning and implementation recommendations, and provided some session configuration suggestions, to help you keep your sessions as secure as possible.
Planning and implementation recommendations
Many tend to overlook the importance of the planning process when large amounts of time, effort, and energy can be saved if session management is appropriately planned and implemented. We recommend the following:
- Include the appropriate stakeholders in your decision-making processes. Often,
identity and access management (IAM) administrators and engineers begin defining
session parameters without consulting others who will be affected by
configuration decisions, such as product managers, marketing and support
representatives, and application owners.
It’s best to work closely with these stakeholders from the beginning to ensure that you all understand the current and future state of user journeys and that you’re all involved in the decisions made regarding these journeys. Consider using an orchestration tool to help you visualize each path users can take.
- Review process flows to ensure that authentication occurs at the appropriate
time and place. Consider the sensitivity of the data involved in each
interaction and determine what type of security is needed.
There are many ways you can configure application sessions to best meet your needs. For example, you can create rules that drive authentication and determine what users can see and do in an application, or you can map re-authentication methods to actions taken based on risk tolerance and levels of identity assurance.
- Continually monitor your sessions to determine whether they can still be trusted. Track as many interactions as you can and obtain data feeds from as many systems as possible. This data can help you identify patterns in normal behavior so that you can more easily detect abnormal activity. You can use API detection solutions to identify suspicious activity, monitor user behavior, and compare it to known patterns. You might also consider using telemetry monitoring to help you detect irregularities.
- Use risk-based authentication, which requires users to provide additional authentication information if risk signals are detected. The risk level is determined by several unique factors including location, time of day, device and browser information, IP address, user information, and the context of the request.
- Determine what will happen when abnormal activity is detected. Will you end the session? Require users to re-authenticate? Require users to authenticate using a different method? Map out these remediation processes during the planning process and test them before implementation. Orchestration tools are also helpful in mapping out these processes.
- Use passkeys, if appropriate. Passkeys are a safer and easier alternative to passwords. With passkeys, users can sign on to apps and websites with a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern, freeing them from having to remember and manage passwords.
After you and your team implement your session configurations, the real work begins. Continue to review the data you collect and revisit your authentication processes on a regular basis. The threat landscape is constantly evolving, and it’s important that you evolve with it. Technologies change quickly and new attack techniques will continue to emerge, so the session configurations that you establish today might work well, but might not work quite as well tomorrow.
Session configuration recommendations
Hijacking attacks, man-in-the-middle attacks, and fixation attacks most often occur when either the session ID or session cookies have been compromised. To protect them as much as possible:
- Use HTTPS instead of HTTP
- When HTTPS is used, all communication between the user’s browser and the application is encrypted, which means that even if an attacker manages to intercept the traffic, they cannot read or tamper with the data. HTTPS also provides authentication, which ensures that users are communicating with the real application and not a fake application set up by an attacker.
- To protect cookies, we also recommend enabling the following attributes:
Secureattribute so that they will only be sent over HTTPS.
- Create secure session IDs and cookies
- To ensure that attackers can’t predict session IDs, it’s considered an industry best practice to randomly generate session IDs that are a unique combination of letters and numbers at least 128 bits (16 bytes) long. This ID is simply an identifier and should not contain sensitive information.
- When the session ID is created, a session cookie is also created to store the ID. It’s a good idea to store session IDs in a different cookie from other sensitive information, such as a username. That way, even if an attacker manages to obtain the cookie, they won’t be able to hijack a session without knowing the username.
- It’s also a good idea to encrypt session IDs so that attackers cannot read them without having the encryption key.
- Limit the number of simultaneous sessions per user
- If an attacker were to gain access to a user’s account, they could do whatever they want. However, if you limit the number of simultaneous sessions available to each user, the application will only be available from one device at a time. This doesn’t mean that users can only access the application from one device. It means that users can only be signed on to one device at a time.
- Regenerate session IDs
- To protect session IDs, we recommend regenerating them after users sign on to the application because it makes it much more difficult for hackers to exploit session IDs. It’s also important to regenerate session IDs when users’ privileges change.
- If a hacker hijacks a user’s session, they will have access to the user’s account with all of the privileges that the user has. However, if the session ID is regenerated after a significant privilege change, the hacker will no longer have a valid session ID, which makes it more difficult for them to access the user’s account and escalate their privileges within the application.
- There are two ways to regenerate session IDs:
- The first is to invalidate the old session ID and create a new one. This approach is the most secure, but it can cause problems if the user has multiple tabs open because they will be signed out of all of them.
- The second is to change the secret key associated with the session ID. This approach is less secure but provides a better user experience because it doesn’t sign the user out of other open tabs.
- Destroying the session ID when users sign off is also highly recommended, as you invalidate the session ID and make it much more difficult for an attacker to hijack the session.
- Invalidate all open sessions when passwords change
- If an attacker obtains a user’s password, they could use it to access the user’s account. However, if all open sessions are invalidated when the password change occurs, the attacker will be locked out of the session.
- Expire sessions based on user inactivity and risk tolerance
- The longer sessions last, the more vulnerable they can become. The amount of time sessions should last depends on the sensitivity of the information exchanged between the user and the application and the level of identity assurance.
- For example, an e-commerce retail company might not have any concern about their users being signed on for long periods of time, especially if the user is just browsing and hasn't authenticated with the application. However, most financial institutions do not allow their users to be inactive for longer than 15 or 20 minutes before the session expires as the risk of fraud and theft increases.
To learn more about session management and authentication, see:
- PingAccess server-side session management configuration
- PingFederate session configuration
- PingOne Platform API Reference
To learn more about monitoring solutions, see: