I am writing a service-oriented (REST) application that is (nearly) totally stateless: it can authenticate by API keys, but for web UI it uses the session where it stores nothing but an authenticated user's ID (int). Session ID is generated randomly as it's usual to see, user ID's are never exposed to the users as users are always referenced by their username
Here's the idea I got. What if instead of assigning random session ID I would generate it in the following fashion:
N1 random bytes not including flag byte + flag byte + user ID + flag byte + N2 random bytes;
or in other words, N random bytes containing a scannable ID somewhere within, all encrypted with server's secret key. It's also possible to use client's IP as a part of the string or as IV, to mitigate session hijacking.
The benefit of this approach is that the need of session is completely eliminated, and for scalability matters it's only required that all nodes use the same secret key (session replication is not required either). With regard to performance I'm not sure whether in-memory decryption (let's say, 128-bit AES) would be faster or slower than reading session data from disk and pruning it time to time. The only attack vector I can think of is attacker creating two accounts in a row (so that ID's are sequential) and bruteforcing their two session ID's to obtain the secret key (which, I believe, would not be feasible if it is effectively long).
What I want to ask is:
- What do you think about security of such approach? (I'm concerned since the only recommendations I have seen so far is "use strong random for session ID's", and never read about such encrypted session ID approach — but that might be just people really loving to use session to store data there);
- What are the possible ways of cryptoanalysis beyond the described one?
- What are the downsides, beyond possibly long session ID?
- Is it a known approach (then where is it documented?)