What is the Session Random Number?

Each time a user access Snap! Websites pages, he receives a cookie. That cookie include a session identifier and a session random number defined as:

<session identifier>/<session random number>

The session identifier does not change between accesses unless something goes wrong. The session random number changes on each access. This allows us to prevent the use of a session by a hacker for more than one page access if both the hacker and the user being hacked both use the site at the same time. Figure 1 shows a normal session with a "random" number:

Figure 2 shows a hacked session, we see that as soon as a second user access the site with the same random number, the session is closed on both users:

In Figure 2 the hacker finds out your session number: 6F32/2. He puts that in his browser and proceed to a secure page. At that point the server sends a new session number: 6F32/3. Just a little later the normal user attempts to access another page. At that point the normal user cookie still says 6F32/2 and that does not match the current session: 6F32/3. The server automatically logs the user out, he can continue as an anonymous user.

Note: Obviously the numbers presented in Figure 1 and Figure 2 are not the numbers used by Snap! Websites. All those numbers are much larger and fully randomized.

Testing the Session Random Number

All you need in order to test that the session random number works are two browsers and know how to find the browser cookies.

In the first browser, go to the Log In page. Enter your email and password. Go to a top secret page (a page that an anonymous, non-logged in person could not see).

Search for your Snap! Websites cookie and copy it in your clipboard (Ctrl-C or Apple-C). The cookie is named users__snap_session.

Go to your second browser, go to the website as an anonymous user (i.e. do not log in). Paste the session information in your cookie. Go to a top secret page (a page that an anonymous user cannot access, but the user who logged in using the first browser can.) It works! You just hacked your own session...

You can browse as long as you want in the second browser (at least untile that cookie / session elapses) until you go back to the first browser.

Click any link, button, or click Reload in the first browser. Notice that you got logged out.

Try back in the second browser, you cannot see top secret pages anymore. You got logged out.

Fast Asynchroneous Connections

Unfortunately, clients have the right (and Firefox takes it!) to access websites using multiple connections. What this means is that having a new random session number of every single connection is not possible without the risk of losing the session altogether.

For example, Firefox will send the GET request to retrieve the page just before sending the GET request to retrieve the favicon.ico. Not only that, it then starts sending connections for each file defined in the HTML page: CSS, JavaScript, Images... all of those asynchroneously (in most cases they use just 2 connections.)

This means the mechanism to detect whether a session was hacked happens to legitimate users simply because the client decides to accelerate the download process of the page as a whole.

The result is that in practice we change the random number only once every 5 minutes. This should be enough to prevent most attacks that this technique offers because most attacks will take more than five minutes to capture a victime anyway.

Later versions of Snap! may be better capable of detecting the type of data and choose whether the random number should be changed (HTML page) or not (CSS, JS, Images...)

Increasing Session Security

We plan to add other variables to increase the security of our sessions. For example, we can test the User Agent (i.e. the name of the browser used to access the site). If the User Agent changes at all, we can log out the user.

The IP address is another security. There is one problem with the IP, many devices change their IP address over time. That would have the side effect of kicking out users...

If possible, use client side only information to check on the date and time of the last access. If the mismatch is too large, then we can assume that the session was used by someone else.

Auto-log out sessions that do not get used for a long time. Or at least reduce rights after say 1h, so a hacker would not be able to do too much against that account.

One (Safe) Drawback of the Session Random Number

There is on drawback of the session random number mechanism. Note that this applies to all dynamic websites that use a similar technique (and pretty much all modern CMS use this capability.)

A user logs in, goes to a page, and another... then he clicks a third time, the GET request is sent to the server and the user loses his Internet connection. At that point, the server generates a new session since it received the GET request. That session is assigned a new random number and the server attempts to send result back to the user... but that fails since the connection was lost in between.

At that point the Session Random Number is out of synchronization and thus the next time the user comes on the website, he gets logged out automatically.

Since this does not happen very often, this is an acceptable behavior of the session plugin.