Is a session token enough for critical applications

Question

So for years I have been using various user checks on top of the session token they are issued to maximise security.

I am now looking at developing a session system across separate servers and am wondering whether this is still relevant.

Considering Oauth does not use any of these extra checks and is widely used, can a session token on it's own been thought to be reliable? Google and Facebook would appear to think so.

The extra checks such as IP and user browser information can all be stolen just as easily as cookie if that line of attack exists.

So will it be ok to concentrate on well formed session tokens as opposed to adding the extra measures.

This page lists the typical extra measures used PHP session security

Before I get jumped on, I understand how Oauth works, but ultimately it results in a single session token for validation once the session exists.

Answer 1

If you use cookies to store session ID's just make sure it is set in a cookie with the Secure and HttpOnly attribute. Restrict the domain and path attributes as much as possible. Make sure no untrusted web application is hosted on a related domain who could launch a session fixation attack. Set a reasonable expiration time for the session. Serve all your pages over HTTPS since mixed content might leak your session ID. Try to limit the externally loaded JavaScript libraries to minimize the attack surface.

Some application servers like Tomcat allow you to use SSL session ID's instead of session ID's stored in cookies. These SSL session ID's are better protected but you should be able to share the SSL session over multiple servers in your case.

A lot more tips can be found here: Session Management Cheat Sheet

EDIT:

They are no working on binding tokens like session ID's to a client via public-private key and signing. Read the RFC here. It will take some time before it will be adopted by the major browser vendors but as far as binding a session ID to a client goes, this seems to solve all the issues. Of course there is some key generation and signing overhead and you require client support for this to work.

Answer 2

You need to ensure that

• you have an authentication information - your token for instance
• this authentication information cannot be guessed - the token must have, among others, a good enough entropy and atomicity (one token is generated independently from others, in other words knowing one token does not help you to know the next one)
• this authentication information cannot be fiddled with while in transit - use HTTPS

if you want to further restrict who can authenticate, use client side certificates (since you will be using HTTPS anyway) - they are likely to scale better than IP filtering.

As you mention, tokens are good enough for Google and other big players. They are therefore good enough for me as well.

Answer 3

Session tokens are only useful when transmitted over a secure protocol (like https://). Session tokens without a secure protocol can indeed be stolen easily.

Answer 4

This too long for a comment to Silvers answer, but it uses information from the link he posted and answers my question quite specifically.

Binding the Session ID to Other User Properties

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

This highlights what is kind of a mixed message. On one hand it is suggested that user information is stored and cross-checked to flag up clear hacking attempts, yet it is admitted a skilled attacker can spoof this information.

So you'd have to conclude if you want to protect against skilled hackers and who doesn't that these cross-checks while making you feel better wont actually offer any more protection.