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. > 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
