Hi Rainer, > -----Original Message----- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Friday, February 14, 2014 11:07 PM > To: Tomcat Developers List > Subject: Re: Special requirements on session id generator > > On 14.02.2014 19:14, Konstantin Preißer wrote: > >> Fortunately I don't have to prevent any long term collisions, just > >> reduce the rate without increasing session id length. Therefore I prefer > >> not to keep state for a long time including tomcat restarts, or do > >> remote (database) calls to check ids whenever a new one is generated. > > > > While adding some information like the current time probably reduces the > possibility for collisions, I'm concerned about the security implications. > > I understand that your requirement for avoiding collisions of session-IDs > between 30 days is to ensure that a client that gets a specific session-id > does > not try to reuse it some time later and, by chance, hits a session that has > been assigned to another user but uses the same session-ID. > > No, it is not about reuse and also not really about security. The > session id is used in some back end as well and it does not allow the > transaction to proceed if the same session id had been used during the > last 30 days. Let's say it is a flaw in the back end system we have to > work around.
OK, then I misunderstood your requirement, sorry. So appending timestamp should be OK for this, although I personally would prefer to use a counter value that increments by 1 for each generated session-ID. > > However, e.g., if some attacker knows that you add a time information to > the session ID, he could just try to re-use the session-id and add some > timestamp values, as the time value isn't a random value that cannot be > predicted, so I don't see a security benefit here. (Maybe one could then run > a hash function over this combination of random bytes + timestamp so that > the attacker doesn't know the original session-ID, but this would probably > cause some other problems.) > > Right. That's why I don't want to reduce the number of random bits in > the session id. The additional timestamping is just to increase the > likelyness that the same id isn't used again, it is not about > security/predictability. Since in my case we are a boit limited in the > number of characters the id can have and adding a timestamp reduces the > space available for the encoded random data, I want to switch from hex > encoding to a more dense ascii encoding that allows the same amount of > random bits in a shorter string. Ok. > > > Personally, the only secure way to avoid collisions over a period of time > that I can think would be to store the generated IDs somewhere and check > them when they are generated. However, one would need to increase the > number of bytes that are used for the session-ID to ensure that the number > of possible session values at any time is at least as high as when not > checking > for collisions. > > Correct. > > > However, when viewing this from an wider perspective, I don't think that > such collisions are a real problem - the client could just generate some > random value by it self and try to use it for a request, to see if the > session-ID > is currently in use. More important would be that the number of bytes that is > used for generating a Session-ID is so high that a client has a vanishing > chance > of hitting a valid session-ID, regardless of whether the value that he uses is > one that the server generated previously, or one that is randomly generated > by the client. > > This is not about ids being currently in use :). It is about the same id > being generated a second time by the id generator days after it was > originally in use. And the goal is to reduce the rate with which this is > happening without reducing the random part of the id to much. > > I'd do an impl of pluggable id generation in order to not have to switch > the manager impl. I don't think that the replacement id generator used > to scratch my itch is of general interest. Being able to plug another > impl does sound reasonable though. > > Regards, > > Rainer > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org Regards, Konstantin Preißer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
