tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik <fi...@hanik.com>
Subject Re: Special requirements on session id generator
Date Fri, 14 Feb 2014 22:34:17 GMT
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 <kpreisser@apache.org>
wrote:

> Hi Rainer,
>
> > -----Original Message-----
> > From: Rainer Jung [mailto:rainer.jung@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-unsubscribe@tomcat.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@tomcat.apache.org<javascript:;>
>
>
> Regards,
> Konstantin Preißer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@tomcat.apache.org <javascript:;>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message