tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Preißer <>
Subject RE: Special requirements on session id generator
Date Fri, 14 Feb 2014 22:20:29 GMT
Hi Rainer,

> -----Original Message-----
> From: Rainer Jung []
> 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.


> > 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:
> For additional commands, e-mail:

Konstantin Preißer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message