regardless of the use case, a debate whether to make something pluggable or extensible c(sh)ould be short. adding pluggability/extensibility that doesn't change default behavior can actually leave the exact use case out of the question.
On Friday, February 14, 2014, Konstantin Preißer <kpreis...@apache.org> wrote: > Hi Rainer, > > > -----Original Message----- > > From: Rainer Jung [mailto:rainer.j...@kippdata.de <javascript:;>] > > 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 <javascript:;> > > For additional commands, e-mail: dev-h...@tomcat.apache.org<javascript:;> > > > Regards, > Konstantin Preißer > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@tomcat.apache.org <javascript:;> > >
