On 2001.12.27, Wojciech Kocjan <[EMAIL PROTECTED]> wrote: > As I mentioned before, I use 32 bytes long mostly random SessionIDs - > that is, there is no ID related to database. The only way to hijack a > session is to guess (or probably sniff :) the 32byte ID... > > I have no idea how to effectively protect against that.
Or, exploit a bug in the user's browser and ask it (via JavaScript, probably) for the cookie for your site to be sent to my (malicious) server. Then, I've got your session ID. Equivalent to sniffing, I guess. That's why I said use some difficult to tamper with method (I suggested symmetric key crypto as it's easy to implement) to encrypt a sequence number (which only increases, or only decreases, etc.) that gets sent along with the session ID. Even if someone "sniffs" the session ID and the encrypted sequence number, it will do them no good since you'll prevent replays by checking the sequence number: if it's already been used in the past, reject the attempt to use the session ID. Your overhead becomes: updating the encrypted session number on every page hit, and keeping track of the most recently used sequence number on the server side to prevent replay attacks. It's pretty simple to implement, just "costly" in terms of server-side CPU cycles. Which sucks, if you do a lot of volume in traffic. But, the approach should be scalable, so ... If my explanation doesn't make sense, maybe I'll provide a simple implementation in my nssession reference implementation. Maybe. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
