Security implications of session strings that are not stored in a server database?

Question

This time I am going to be brief :-)

Instead of issuing randomly generated session strings to a user and inserting them into database, mapping these to user identifiers, for subsequent lookup on every authentication, why not do the following, with the intention to avoid database access on every request and distribute the session store instead:

1. Take the user's identifier
2. Take a chosen expiry (date and) time
3. Put the two above together
4. Pad them with a 'salt' - here a secret string of (a longer) arbitrary length
5. Encrypt the resultant string with a secret encryption key

The result would be a string that is sent to the user (using HTTP Cookie mechanism) as the session key. Obviously, on authentication, the procedure is reversed by the server again, to extract a user identifier. If the expiry datetime checks out, that is. The session string would be considered infeasible for the client to cook up himself, because a brute-force attack is required where a large amount of salts and large amount of decryption keys will have to be tried, plus a correct structure of the unencrypted data has to be guessed.

My question is: what are the security related implications of the method I outlined? In my opinion, obvious advantages are:

1. The sessions are not in a centralized store, but are distributed instead.
2. Expiration value still ensures that these distributed sessions do not circulate indefinitely.
3. If decryption is speedier and less complicated than database access, the method is obviously faster as well.

Answer 1

I like this method and I use it for my websites because it's easy to scale with that.

The only security issue I see with this protocol on HTTP is that your requests are vulnerable to replay attacks/sniffing. By the way, the same issue exists with session IDs stored in cookies on a non encrypted transport protocol, except if you regenerate the session ID on each request.

Extra reading : a PHP implementation wich includes a link to a great paper on this subject (sorry I can't post more than one link on stackoverflow at the moment ;).

Answer 2

What do you want to use to encrypt/decrypt the data?

Generally, I wouldn't suggest doing what you told us about above because:

• Why not have all the sessions in a centralized store? Your encryption algorithm could be stolen/cracked as well.
• Database access will be most likely faster and easier to manage/code

If your source code is stolen or the algorithm is broken, attackers could create new, custom session and make themselves admin - you can image the rest yourself

Have you though about using the standard session library in PHP?

Answer 3

The weakness of the system is that the 'logged in' token is sent plaintext in a cookie, and this is the same weakness whether the token is in a database or not, and is guarded against by using HTTPS connections.

Having said that, most sites don't use HTTPS. They make a trade-off. If you don't use HTTPS, and you want to compare sending a authenticated cookie vs sending a cookie is a database key, then there is nothing week in the former compared to the latter.

It is a good idea to include also the IP address of the request as well as the expiry date.

It is unnecessary to store the token encrypted in the cookie, however - it is equally secure and rather more straightforward to send plain-text credentials and then a cryptographically secure hash of the credentials and the secret. See HMAC for details. HMAC is basically:

Imagine that the variables username, expires, ip_address and a salt (a random number) have been stored in the HttpOnly cookie; you extract them, as well as your hash that was also in the cookie. In your script you have an additional 'password', which is never directly stored in the cookie:

hash = hash_hmac("sha256",username+expires+ip_address+salt,"password")

The security of this hash is based upon the quality of the password. This should be some random string of digits and letters and punctuation and be at least 20 characters long, which is stored in your server-side scripts.

If the hash in the cookie is correct, you can be certain that the fields that were hashed have not been tampered with! The chances of an attacker generating a meaningful collision would be gazillions to one [1] - certainly beyond the compute power of all the computers in the universe and a bazillion years. Its that secure, if your password is something sensibly random.

But the whole system is only a speed-bump to a determined attacker, and is only appropriate for normal websites rather than things including payment or a user-expectation of security. Without HTTPS the system is not secure, and with HTTPS the authentication of the cookies is unnecessary.

A determined attacker could access your site to recover the password - there is nothing stopping them recovering the login details to a database in the same circumstances, so no different from the database approach outlined in the question in this regard.

A determined attacker could copy the credentials, and send nasty requests on behalf of the user, e.g. csrf and so on.

And so on.

[1] I understate the odds.

Answer 4

Not a good idea. A very similar (and fundamentally, if I understand correctly, indentical) question has been asked a few weeks back. My answer was (I added the emphasis to underline the core point):

Storing vital data like session expiry and user name entirely on client side is too dangerous IMO, encrypted or not. Even if the concept is technically safe in itself (I can't answer that in depth, I'm no encryption expert), a break-in could be facilitated without compromising your server, just by acquiring your encryption key.

Somebody who gets hold of the key could generate session cookies at will, impersonating any user for any length of time, something the classical session concept with its centralized storage of session data is designed to prevent.

There are better and scalable solutions for this problem. Why not, for instance, set up a central session verification instance that all associated servers and services can poll? Look around on the web, I am 100% sure there are ready-made solutions addressing your needs.