Can user session keys not stored by the issuing server, be considered secure?

Question

Instead of a server issuing randomly generated session strings as service access keys (aka "authentication tokens") to a client, inserting them into database to maintain a set of user-key relations, for subsequent validation on every service request, may a server not do the following instead to achieve comparable or better security in the thus distributed system:

1. Take the user's primary key (aka "user identifier")
2. Take a chosen key expiration timestamp, and, optionally, the IP address of the client, and whatever else may be worth embedding in the key
3. Take a secret string as the key verification signature
4. Serialize all of the above
5. Encrypt the result, symmetrically, with a key only known to the server, or asymmetrically using server's chosen private key

The session key that is the result of the steps above, is then shared with the client, e.g. with a cookie. With a stateless protocol like HTTP, where every request has to prove client authentication using a session key, the procedure described above is done in reverse by the server, with the goal of recovering an authenticated user identifier.

Everything else being equal, a successful attack on the underlying cryptography would be required for an adversary to be able to forge session keys and thus compromise the security of this system. With "everything else" I refer to weaknesses like the adversary obtaining user's session key from the client somehow with the intention to use it themselves.

The advantages of the approach, that I see, are:

1. No need to maintain a valid user-key relation set anywhere
2. Expiration value embedded in each key ensures that keys cannot be used beyond a certain point in time, by anyone.
3. Decryption-based verification by the server may be less costly than database access.

The disadvantages may be:

1. Invalidating keys by the server may be considered problematic:
   • Even if a key securely embeds e.g. an IP address, where the server may use the latter to validate the key by comparing the embedded address to the address behind the service request, an IP address may be forged
   • If key revocation problem is solved by the server maintaining a set of revoked keys, one may ask how this is better than maintaining a set of user-key relations in the first place?

I consider this question closed as it may not ever have a single acceptable answer and does not hence fit the SO guidelines, but since it has remained open and has gotten useful answers, I won't delete it, at least.

Answer 1

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 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

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 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.