Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How are session IDs generated?

 
Ulf Dittmer
Rancher
Posts: 42967
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I assume they are a hash of something, but does anyone know more about the algorithm? Like which pieces of information go into the hash, and within which timeframe IDs could conveivably collide? Any links are appreciated as well.

Thanks,
Ulf
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13058
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why not look at the Tomcat source code?
Bill
 
Ulf Dittmer
Rancher
Posts: 42967
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know, the source is my friend. But I was hoping that someone had more insight, or had done the source-spelunking already.

Edited later: The session ID is a 16 byte random number, run thorough a digest (MD5 by default), and then converted to Hex.
[ August 01, 2005: Message edited by: Ulf Dittmer ]
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
just being curious. lets say several users (user A, B, C, D and E) interacted with server.
and then, the server is restarted, so all sessions are all destroyed.
then comes user F and F also got new session. my question is, is it possible the newly generated session id to be the same as sessions still retained by user A - E?
if it is, then this would be a security breach as user other than F theoretically will have access to F's data.
is this the case with tomcat?
thanks
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18098
50
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, the default behavior for recent versions of Tomcat if the server is restarted is that the sessions persist over the restart (they're stored in the work directory as ".ser" files).

The sessionid-generating algorithm, like all hash algorithms can potentially come up with an identical ID, but the whole point of designing the algorithm is to minimize that possibility. I like Brockschmidt's quote about the chances of 2 GUIDs generating the same as "about as likely a a bunch of atoms out in space suddenly rushing together to form a small walnut".

Incidentally, if you switch from normal to SSL security in Tomcat, the session remains, but the old jsessionID is discarded and a brand-new one is generated. It still refers to the same session, but that way people cannot tap into secured communications using the unsecured handle that was public visible (unencrypted) - it's no longer attached to anything.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic