--- In zope@egroups.com, "Chris McDonough" <chrism@d...> wrote:
Without a client-checking scheme (such as encoding the IP address in the token), a token theft attack is very easy. As voiced by others in the thread, client-checking is not reliable, should not be a default, and maybe shouldn't be included as an option at all.
I would like to control finely the session security mechanisms. I would like to be able to plug a client-checking (or anything else). This way, each WebApp developper can discriminate among its own constraints and risks. I want to be able to use different ways to secure the session. For example, ther would be cases where I would implement a client-checking mechanism based on both IP address and browser time-limited cookie. This would allow me to follow sessions on people refusing cookies and on people behind "IP dancing" proxies. I would loose session state for anyone both refusing browser cookie and being behind "IP dancing" proxy. This would be an acceptable compromise if I am manipulating highly private data. In other cases, I could accept lower-level security related to the less privacy. Godefroid Chapelle --------------------- BubbleNet sprl rue Victor Horta 30 1348 Louvain-la-Neuve Belgium --------------------------------------------------------------------- This mail sent through SwinG Webmail: http://mail.swing.be