Hi
Now I have been thinking about this a little more. I have now understood that there is one attack vector that I had not been thinking of. The session id length and its randomness is an important factor but the timing attack can exploit the database indexing functionality in order to reduce the session search space and thereby reduce the "search for all possible session ids" to something much smaller.
I think the attacker needs to be very close, or at least on a connection to the server with a very predictable timing making a live server exploit difficult from a distance. Potentially possible.
This is a general problem for most kind of services and I do not think it is limited to ruby-rack. It just happen to be so that we have a specific CVE for ruby-rack. Others may have exactly the same issue.
The solution to look up the hash of the session id makes sense. It makes things much harder to exploit.
The best solution as I see it is to do one the following:
alternative 1:
At upgrade change all database session keys to the hash(key) and then only lookup using the hash of the session id key.
There is no need to change the interface at all as I can see it.
alternative 2:
No change at upgrade. At lookup look for the hash(key) and if that fails look for the key. To improve the security we can introduce a random delay between 0 and ... well the time a lookup take worst case.
Still no reason to change the interface as I see it.
alternative 3:
Do as upstream. The problem is that upstream introduced an API change in a non-backwards compatible way. This works for unstable, but I do not think it is preferred for oldstable, oldoldstable or stable.
Which one to choose. I think alternative 1 is the most secure option but the upgrade may be complicated and is a little fault prone. I think alternative 2 is good enough, especially with some random delay.
Hope this helps.
Best regards
// Ola