Client side sessions

Question

I want the clients of several related web apps to hold their own authentication state. This improves scalability, because no session replication between cluster nodes is needed. And it makes integration of different server technologies like Java Servlets and PHP easier.

My plan is as follows:

1. Set a signed and encrypted cookie with the user name and session expiration time after client authentication.
2. When the client sends a request, the server decrypts and validates the cookie and grants or denies access depending on the cookie values.
3. The session expiration will be updated through resetting the cookie.

All servers that want to use the session have only to know the cookie mechanism and the decryption key. See also: Session state in the client tier

Is this approach ok? Would it be possible to integrate it into a servlet container / application Server so that it is transparent to the applications? A servlet should be able to use HttpServletRequest#getRemoteUser() for example. Is this possible? Or would I need something above the container level like Spring Security? Are there any existing libraries for client side session management?

Crinkleroot

Answer 1

Not a good idea. 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 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.

Rhodarhodamine

Although this is rather an old discussion, its still highly ranked when searching for information about client side session data. Someone who can acquire the session key implies someone with access to the session data in the first place, therefore the argument is weak. But there are better strategies than using a single static key. And key rotation is relatively simple to implement. The biggest challenge to the approach is ensuring the session data is included in every relevat request from the client. – Tucci

Answer 2

I disagree with the posters saying this approach is not secure. Variants of it are used in a number of well respected frameworks, such as Rails and Play!, for precisely the reasons you outline, and it's perfectly secure when implemented correctly.

Heroine

Answer 3

This improves scalability, because no session replication between cluster nodes is needed.

First, using HTTP Session doesn't really prevent you from scaling, even when using HTTP Session State replication (some mechanisms are smarter than others by the way, for example WebLogic's in-memory replication doesn't have a big overhead). Second, do you really need it? Most applications (the majority) don't need Session replication. Third, am I understanding right: do you plan to not use HTTP Session at all?

(...) Set a signed and encrypted cookie with the user name and session expiration time after client authentication.

Don't do this! Don't store a username and other sensible data used by the server in a cookie, this is a very bad idea! You actually need to admit that it's just a matter of time before someone figures out how your system works and breaks it (especially if your cookie is candidate for crib attacks). Sor, really, you should store data in the Session on the server-side and only an ID in the cookie, like things are actually working. This is much more secure.

Is this approach ok?

No. And you don't need this for interoperable single-sign on (if this is what you are trying to build). Just use a centralized authentication solution like CASJasig which has libraries for various technologies.

Abramabramo

I have a question on this. If we store sessionID at cookie and let the client send to server every time for it to identity the cient, can somebody bad stole this sessionID and prevent he this the user? This confuses me since if the bad guy can stole sensitive id data from cookies, then the sessionID actually also sensitive? Am I wrong? Thank you! – Creamcolored

I disagree with comments made here too - session replication might not be a big overhead, but it is very much subject to CAP theorem - hence request routing needs to be tied to session management which is a key issue that client side sessions address. There are a different set of issues with client side sessions. I see no constructive argument against them here. – Tucci

Answer 4

This is not really how Sessions are implemented. The cookie itself doesn't need to carry any data of the session itself, it's just a reference to it.

What the Cookie holds is usually a Session ID which is then linked to the data on the server.

If you don't have a central data session server for the other servers to access, I suggest to get one :).

Baccarat

This is what he doesn't want to do because he wants the solution to be scalable. I think this the only way to go, though. – Rhodarhodamine

I want to have a store for the authentication state. And I don't want to store this state on the server side. I've something like http basic authentication in mind, but want to be more flexible (to support OpenID for example). – Crinkleroot

Answer 5

You can avoid duplication of data in a clustered environment by using a state server - a server that is well known by all the nodes in the clusters and maintains the session data for all the users. Every time a user performs a request, it send a cookie with session id to the applications server; this one should retrieve the session from the state server. This is possible for asp.net development, but I'm not sure how easy Java supports this approach.

Boyse

The Java world must have solutions for this. It's the oldest high-level web platform and used by countless enterprise applications that have encountered the same problem at some point. – Rhodarhodamine

Answer 6

As Pekka said, not a good idea. One can intercept your cookie with sensitive session data. Even with SSL, by using fiddler2 one can decrypt the traffic

Boyse

A didn't mean transport layer security, but encryption of the cookie data itself - for example with GnuPG. – Crinkleroot

You are wrong about fiddler2 decrypting SSL traffic. It is not a hole in the SSL/TLS design, fiddler2 simply acts as a proxy, putting itself instead of a trusted web server, with a autogenerated (and untrusted!) certificate to talk to the client issuing requests and forwarding them to the intended destination posing as a HTTPS client. This is very different than saying that fiddler2 can decrypt SSL traffic. If that would be the case, criminals would have emptied our bank accounts yesterday. – Kirkuk

@amn: true; you only intercept the trafic, got it. Strange that on the given link the title says "Decrypting HTTPS-protected traffic"... this is misleading. It should be "intercepting". As it is said at the fiddler page, it allows "modify HTTPS-secured traffic" hence maintaining the encrypted cookie (as deamon said) is still not secure, as one can change the actual encryoted cookie. – Boyse