I doubt it is very difficult to guess a valid UID. It's a book example, and not claiming to be cryptographically strong. :-) At the time I wrote that section, Tomcat's algorithm was even more easy to guess, otherwise I would have borrowed it. I'm sure Tomcat's improved now. If you're looking for code, that's a place to look. As for times going backward: daylight savings time doesn't change the monotonically increasing counter used as time (happy 1 billion seconds tomorrow, everyone!). And even if you do change the server's time counter back, that just means your globally unique IDs may not be unique, but still only accesses from the same host could get the same ID since the IP is encoded into the hash. -jh- E S wrote: > > erm. So I'm blind. I did find java.rmi.server.UID > (http://java.sun.com/j2se/1.3/docs/api/java/rmi/server/UID.html). > > However, I'm still not sure that this is the best solution (id guaranteed > unique on a host, but is it computationally infeasible to guess a valid one? > i mean, i could just be incrementing a counter to guarantee uniqueness ;) > )--I'd like to hear about other alternatives. > > Also, with respect to java.rmi.server.UID, I was wondering about the > following: > "Creates a pure identifier that is unique with respect to the host on which > it is generated. This UID is unique under the following conditions: a) the > machine takes more than one second to reboot, and b) the machine's clock is > never set backward." > > So if your server is set to a timezone that observes daylight savings, are > you potentially vulnerable for that one hour? > > >From: E S <[EMAIL PROTECTED]> > >Reply-To: "A mailing list for discussion about Sun Microsystem's Java > > Servlet API Technology." <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: generating a truly unique session id > >Date: Fri, 7 Sep 2001 15:06:42 -0700 > > > >So, I thought something like this would be addressed in the archives, but a > >search on "generate unique session id" didn't turn up anything fruitful. > >I'd > >guess that my scenario is hardly uncommon: generate a unique id that you > >can > >send in an email to a user (e.g. > >"http://foo.com/servlets/foo?uniqueId=abc123";) and when the user follows > >the > >link, you look up that uniqueId in your database and return some results. I > >think I've seen sites do something like this for resetting forgotten > >passwords or something. So, the id is only valid once, if the wrong person > >could guess how to generate a valid one, that would be bad since he could > >then appropriate someone else's account, etc. This seems like the kind of > >thing banks would have figured out a best practice means for doing =) > > > >Basically, I was looking for some pointers, sample code, etc. on generating > >a unique session id: > >1. unique across server reboots, etc. --unique in perpetuity > >2. unique so as to be used as the primary key in a database table, > >3. computationally infeasible to guess a correct one (users will be able to > >see instances of these session id's, but given a session id or any number > >of > >them, they shouldn't be able to figure out how to generate another valid > >one > >themselves) > > > >In Jason Hunter's book, he has the following example: > >private static String generateSessionId() { > > String uid = new java.rmi.server.UID().toString(); > > return java.net.URLEncoder.encode(uid); > >} > > > >I can't seem to find references to java.rmi.server.UID() so I can't > >evaluate > >if this satisfies the requirements above. > > > >There's some discussion that's related to this in Bruce Schneier's Applied > >Crypto (page 427-ish) but I have to admit I don't quite follow the > >discussion enough to trust implementing it myself in Java. > > > >I'm so not a crypto person, but surely this is well-tread territory. Thanks > >in advance for any help! > > > >-Eddie > > > > > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > >___________________________________________________________________________ > >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > >of the message "signoff SERVLET-INTEREST". > > > >Archives: http://archives.java.sun.com/archives/servlet-interest.html > >Resources: http://java.sun.com/products/servlet/external-resources.html > >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > ___________________________________________________________________________ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
