Security Risk of Stolen Session ID vs Authentication Token

Question

I was intrigued by the discussion of this SO question as well as the accompanying blog post. I'm trying to better understand the mechanics of the two systems, and one of the questions I came up with is how much worse is it to have a token stolen vs. a session ID?

Here's what I understand so far, and please do correct me if I'm wrong:

A session ID is an opaque reference to actual session data stored on the server. It is safe insofar as it is random enough to not be guessed easily, and the data is safe because it is not directly accessible by or beholden to the front-end. The session ID is stored in a cookie to simplify authenticated requests.

An authentication token is a plaintext segment of JSON user data with a cryptographic signature that verifies the data's integrity. It is tamper-proof because of the signature, so no one can simply come up with their own token. The data it grants access to is safe on the server, except of course what is present in the token (which even then can be encrypted if need be). The token is also often stored in a cookie to simplify authenticated requests.

So here is what I do not understand. The way I see it currently, it seems just as likely that a token be stolen as a session ID, e.g. anyone breaking past my SSL and viewing my token would be able to view a session ID as well. Either event gives the attacker complete access to my account and all associated authorization. So in terms of the event likelihood and the resulting damage, is an authentication token really any worse than a session ID, as the article claims?

The one thing I could see potentially being worse for tokens is if the signing secret were somehow found out, in which case the attacker can do anything with anyone's account, rather than just mine. However I almost want to relegate this to the reasonable unlikelihood of someone first breaking RSA, in which case they can get past SSL, and then what good is a session ID anyway?

Answer 1

I'm the author of the blog post you referenced, as well as the answer to the SO question you linked. Here are the answers you are looking for.

A session ID is an opaque reference to actual session data stored on the server. It is safe insofar as it is random enough to not be guessed easily, and the data is safe because it is not directly accessible by or beholden to the front-end. The session ID is stored in a cookie to simplify authenticated requests.

Kinda. When a session ID is stored in an httpOnly cookie, the cookie itself is cryptographically signed (and can also be encrypted). JavaScript code can never access an httpOnly cookie (the httpOnly flag makes it impossible for JS code to view the cookie).

An authentication token is a plaintext segment of JSON user data with a cryptographic signature that verifies the data's integrity. It is tamper-proof because of the signature, so no one can simply come up with their own token. The data it grants access to is safe on the server, except of course what is present in the token (which even then can be encrypted if need be). The token is also often stored in a cookie to simplify authenticated requests.

Kinda correct, again. Most tokens are stored in HTML5 LocalStorage (in JavaScript) because they are simply too large to fit inside of an httpOnly cookie. Cookies have a maximum data storage size of 4kb. If your token is larger than 4kb (which most are, since people use them to carry user information), then you must store them elsewhere. And the simplest way to store them outside of cookies is... you guessed it, LocalStorage!

Unfortunately, this has serious side effects.

So here is what I do not understand. The way I see it currently, it seems just as likely that a token be stolen as a session ID, e.g. anyone breaking past my SSL and viewing my token would be able to view a session ID as well. Either event gives the attacker complete access to my account and all associated authorization. So in terms of the event likelihood and the resulting damage, is an authentication token really any worse than a session ID, as the article claims?

The likelihood of someone stealing a token from LocalStorage is far higher than that of a secure httpOnly cookie being stolen. And it's also substantially easier for a stolen token to cause mayhem because:

• A stolen token can be used by an attacker to impersonate the user from anywhere (the attacker's network, proxies, etc.)
• If an attacker is able to inject JS code onto your website, this won't allow them to access cookies, however, so that means the attacker would only be able to run JS code to 'impersonate' a user while the user is still on the website. Because once the user closes the tab in their browser, the JS code the attacker was running will no longer run.

There are vastly different abuse scenarios here.

The one thing I could see potentially being worse for tokens is if the signing secret were somehow found out, in which case the attacker can do anything with anyone's account, rather than just mine. However I almost want to relegate this to the reasonable unlikelihood of someone first breaking RSA, in which case they can get past SSL, and then what good is a session ID anyway?

You're right that if an attacker can figure out the signing key, then they can tamper with an existing token (or create their own fake ones). But, this is highly unlikely because signing keys must be kept server-side. If you accidentally leak your signing key, for example, that's essentially the same thing as sharing your sever password with someone: obviously you're going to have a bad time.

The main difference here is in how the abuse can unfold. The article I linked to above is another post I wrote which details this in much more explicit ways. Hope this helps!