Can I trust a session Id for uniqueness?

Question

I have an old ASP classic web app that generates an Id for a user when they log in. The Id is put into an authentication cookie in plain text and also stored in the database.

Inside of this website, I'm creating a new website. Since it will have the same web domain, it has access to the cookie. My plan is to look up the cookie and use the Id to look up the logged in user in the database - as the classic ASP site is doing.

So, my question is, is this a security risk? I think the opportunity is that someone guesses the generated Id - it doesn't look cryptographically secure to me. If I edit the ASP classic website to use, say, a GUID, would that be satisfactorily unique?

I suppose the weakest link is the original site, so the new site would not be making the overall system less secure.

Answer 1

Although there is an accepted answer here, it is somewhat misleading.

Can I trust a Session ID for Uniqueness?

If uniqueness is the only constraint, then the short answer is yes. If you are Facebook or Google, then due dilligence would require that you take some time to assess how likely collisions are based on the algorithm and the architecture of the application. For applications where the concurrent userbase will be less than a million, the method implemented in common platforms should be sufficient.

However uniqueness just addresses the functionality of the system. From a security viewpoint you need to ensure that the session id is not predictable - i.e.

• that cannot be inferred from available data; md5(CLIENT_IP) would be a poor session id

• that attempting to brute force guess the session id is difficult; next_session_id=last_session_id+1 would be a poor choice

If you really must implement your own session id generation, then use a good random number generator. Have a look at the size of the session ids your current system is generating and aim for at least that size in your implementation.

user52472 said:

Storing session tokens in the database could allow an attacker to impersonate other users if they can gain access to these tokens via a SQL injection attack

Given that the whole point of server side sessions is predicated on server side storage, this can be better stated as:

Storing session tokens on the server could allow an attacker to hijack sessions if they are able to inject code which reads the storage

....although the nature of SQL is such that it is usually the low hanging-fruit of code injection.

One solution is to not store the session data against the session id, but a transformed representation of it (e.g. sha1(session_id + salt)) but this is only provides limited benefits - if the salt and mechanism are exposed, the mechanism is inneffective. OTOH this easily translates to other storage substrates.

If the sessions are stored in a relational database then its possible to protect against enumeration via code injection by disallowing direct access to the underlying table by the account used by the application - instead restrict reads and writes to a single record based on the key (session id) supplied as an argument to a stored function with privilege separation.

Answer 2

You are correct, the old site is the weakest link. I see two possible weaknesses:

1. The session token is not cryptographically random.
2. Storing session tokens in the database could allow an attacker to impersonate other users if they can gain access to these tokens via a SQL injection attack.

For the first one, it's a matter of getting a cryptographically secure random number, and making sure it has enough bits. I'm not too familiar with classic ASP, so I couldn't tell you the best way to accomplish this.

For the second, I would recommend letting the framework handle all of the session management whenever you can de-commission the old site. This would also solve the first problem.