[Zope-dev] Re: CoreSessionTracking proposal
--- In [EMAIL PROTECTED], "Chris McDonough" [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: CoreSessionTracking proposal
i.e. it is secure if the key *is* the data, rather than a key to the data. Can you explain? I do not see what you're getting at. Consider how the tree-tag stores its 'session' data. Its impossible to hijack a tree-tag session because the 'session' state is stored by the client (in the URL) in full. There are other differences between this type of session and the CoreSessionTrackingProposal; but the advantages are not all one way. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
Toby, Sorry, I'm still not sure I understand. :-( Are you suggesting that the session token should actually store session data? Or are you just pointing out the difference between the implementation an implementation that meets the requirements of sessions and an implementation adequate for things like the tree tag? Toby Dickenson wrote: i.e. it is secure if the key *is* the data, rather than a key to the data. Can you explain? I do not see what you're getting at. Consider how the tree-tag stores its 'session' data. Its impossible to hijack a tree-tag session because the 'session' state is stored by the client (in the URL) in full. There are other differences between this type of session and the CoreSessionTrackingProposal; but the advantages are not all one way. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: CoreSessionTracking proposal
Are you suggesting that the session token should actually store session data? As an alternative SessionManager, it appears to have some advatanges that others do not. It is the only option (AFAIK) that avoids the session hijacking problem without relying on security-through-obscurity (the problem you mentioned, but its not one that gets me excited). Its also the only sensible option that lets you bookmark your place in a session, and return to it much later (which interests me more). Or are you just pointing out the difference between the implementation an implementation that meets the requirements of sessions and an implementation adequate for things like the tree tag? Isnt the tree tag an example of one Session use case? It smells alot like a session to me. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
Are you suggesting that the session token should actually store session data? As an alternative SessionManager, it appears to have some advatanges that others do not. Hmmm. Please smack me if I'm wrong, but I'm not clear on how it differs much from not keeping session-related data in the token. I guess you could argue that a session token that holds application data is "more random" due to the nature of its composition, and due to that it can't be "guessed" as easily (I doubt anyone would even try). One of the purposes of the random element of the session token in the current implementation is to address this "token guessing" risk. However, in either case (app data in token or app data key in token), if the token is stolen, it can still be used by the "robber" to see the data that relates to it (made available by the application which relies on the server's unpackaging of the token). This is a different risk, the "token theft" risk. Example: if you get a tree tag token from somebody, and plug it into a URL on your browser, it'll work happily. 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. But all of these ponderings are kind of moot, because session data can be arbitrarily large (session data on the order of a megabyte will probably not be uncommon), so the data can't realistically be embedded in the token anyway. Its also the only sensible option that lets you bookmark your place in a session, and return to it much later (which interests me more). I don't understand what you mean... a session token that doesn't include application data has the same property. That's essentially its reason for being around at all. (If you're concerned that the session token isn't URL-compatible, it is... the current implementation lets the session token be transferred via a query string, inlined URL elements, or as a cookie value). Parts of the token *never* expire, so you can happily bookmark something with a token value embedded (or receive and continue to resend a persistent cookie). Isnt the tree tag an example of one Session use case? It smells alot like a session to me. Probably, yes. Although it will probably not be reimplemented to use the session machinery in the near future (dont fix it if it aint broke! :-). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
I suppose I could implement something like this (encode the IP address into the token) and provide a knob to turn it on and off on the id manager. I'm not going to do this for the first iteration, I need to get it working first. :-) Steve Spicklemire wrote: I forget now where I saw this but one of the session managers I looked at once checked the IP address of the visitor to make sure it was the same for the entire session, or longer. This at least makes it much harder to hijack a session, even though it means that long-lived cookies might be fooled as a user gets a new dynamic IP address... -steve "Chris" == Chris McDonough [EMAIL PROTECTED] writes: Chris Session tokens, AFAICT, cannot be secured. They can only Chris be obfuscated, which mitigates the risk that they will be Chris guessed. However, there's no way to completely secure Chris them, no matter how many MD5 hashing algorithms you run on Chris them. If a session token is stolen, that's the key that Chris the "attacker" needs to visit the website "as you". I've Chris addressed this in the implementation by giving the session Chris token a random element, and this mitigates a guessing Chris attack, but not a theft attack. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: CoreSessionTracking proposal
--- In [EMAIL PROTECTED], Chris McDonough [EMAIL PROTECTED] wrote: I suppose I could implement something like this (encode the IP address into the token) and provide a knob to turn it on and off on the id manager. I'm not going to do this for the first iteration, I need to get it working first. :-) Steve Spicklemire wrote: I forget now where I saw this but one of the session managers I looked at once checked the IP address of the visitor to make sure it was the same for the entire session, or longer. This at least makes it much harder to hijack a session, even though it means that long-lived cookies might be fooled as a user gets a new dynamic IP address... I think WebHub is using the IP address. WebHub is a product built and working witrh Delphi. I tried to find where they mention it on their website (http://www.webhub.com) but could not find it. In fact, if I remember well the server remembers the IP address (instead of crunching it into the id) and check the correspondence between the session id and the IP address when answering request. I was told that some ISP change your IP address during a connection but never took the time to check if it is true. -steve "Chris" == Chris McDonough [EMAIL PROTECTED] writes: Chris Session tokens, AFAICT, cannot be secured. They can only Chris be obfuscated, which mitigates the risk that they will be Chris guessed. However, there's no way to completely secure Chris them, no matter how many MD5 hashing algorithms you run on Chris them. If a session token is stolen, that's the key that Chris the "attacker" needs to visit the website "as you". I've Chris addressed this in the implementation by giving the session Chris token a random element, and this mitigates a guessing Chris attack, but not a theft attack. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org Cheers, Godefroid Chapelle - BubbleNet sprl rue Victor Horta 30 1348 Louvain-la-Neuve Belgium - This mail sent through SwinG Webmail: http://mail.swing.be ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
At 05:17 PM 10/2/00 +0200, [EMAIL PROTECTED] wrote: I was told that some ISP change your IP address during a connection but never took the time to check if it is true. Whether the actual user's IP changes isn't relevant. The question is, can the IP of a proxy server between the user and you change. And that's quite possible. Consider the situation where the round-robin DNS of a bank of proxy servers expires during the user's browsing session, or a bank of proxy servers behind a load balancer on the user's side. Since all the HTTP server ends up seeing is the proxy server's IP, you could potentially have the same user dancing around all over the place, IP address-wise. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
Please, please, please, do _not_ use IP numbers to verify it's the same connection. You guys don't have the problem in .us, but out here at the fringes (.au, and presumably .uk and similar), proxy server use is rampant - and leaning on IP breaks, because proxy's share the connection around. Example: Connect.com.au (backbone provider) have three proxy servers in melbourne, two in Sydney. Their customers have their own proxies. An end user hits the customer's proxy, which requests via ICP from _all_ of CCA's proxies in their region - the fastest proxy at the time responds first. Fastest can, and does, change very quickly when those boxes are close to the same load - a single session often chops between multiple IP's. Then the customer's proxy is also leaning on telstra's proxy's, in a completely different netblock, and sometimes they decide upstream response is too slow and they'll go direct. People leaning on the source IP for verification just means you get more complaints from .au people unable to use your site. I wouldn't even offer it unless you made some passing attempt to get the browser's own IP (use the proxy header, can't remember which one, that reports browser IP), even then I'd be cautious as that's a voluntary header. KevinL (that one's a bugbear of mine ;) [EMAIL PROTECTED] wrote --- In [EMAIL PROTECTED], Chris McDonough [EMAIL PROTECTED] wrote: I suppose I could implement something like this (encode the IP address into the token) and provide a knob to turn it on and off on the id manager. I'm not going to do this for the first iteration, I need to get it working first. :-) [snip] In fact, if I remember well the server remembers the IP address (instead of crunching it into the id) and check the correspondence between the session id and the IP address when answering request. I was told that some ISP change your IP address during a connection but never took the time to check if it is true. [snip] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: CoreSessionTracking proposal
Chris McDonough writes: Dieter Maurer wrote: ... serious privacy concers about long living browser ids ... . This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. Not if you want to associate a session with a browser across a long period of time. For example, if you wish to maintain a long-lived "wish list" of items in session storage without requiring a user to log in. *IF* I wished to maintain a long-lived "wish list", I would understand the need for a long living browser id. However, when session data expires after several minutes idle time (discarding my wish list), I do not understand at all why the browser id should live for a year. I would suspect the issuer to be interested in malicious activity tracking, seriously affecting my privacy. I, at least, care much more about my privacy than about some wish list maintained for a longer term. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. I do not see any reason why a site should be able to track my activity over a longer period of time -- at least no without my explicit consent. The cookie lifetime is configurable, so this is up to the site manager or developer. This is not a problem endemic to Zope or the core session tracking proposal, but to the configuration imposed by the developer or site manager. Lots of people don't mind long-lived cookies, and it's not realistic to limit the functionality of the system based on something that's out of our scope of influence. If you choose not to visit sites that provide long-lived cookies, then perhaps that site's session manager will choose to reduce the cookie lifetime. Your default values are bad: session inactivity timeout: 20 min browser id cookie expiration: 1 year As soon as I would recognize that my session data disappears after some minutes idle time I would question, why my browser told me the site wishes a cookie to be installed with a one year lifetime. What nasty things does this site want a such long living cookie for? Security: * I do not think "Annonymous" should have the permission "Add Session Data Objects". Session handling should be transparent, including allocation of a session data object. The use case description that mentions "add session data objects" is incorrect. That permission will not exist. The overall permission "Access session data" will permit the creation of session data objects, as well as the manipulation of already-created session data objects. Anonymous must be granted this permission (or sessions would be completely worthless, as they would require users to log in). I disagree with this. Anonynous must only access *his/her* session data and must not access session data of any other Anonymous. You have the session id to ensure this. However, the Zope security model is not strong enough, to express this. Therefore, I think, the core should implement a module that handles this special case outside the current Zope security model. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. How do you propose that we recognize one 'Anonymous User' from another? What do you have session id's for? To give a user access to his/her session data. Use it, too, to prevent access to others session data. Especially, he/she should be unable to determine what other session data is available. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
Dieter Maurer wrote: I, at least, care much more about my privacy than about some wish list maintained for a longer term. Sure. That is why you're free to not continually visit sites that implement this policy. (and boy are you gonna hit the roof when you read my explanation of why I changed the implementation to accomodate global session keys! :-) Your default values are bad: Yes, you're absolutely right. I've changed them. The default value in the constructor form signifies that the session id manager should not send persistent cookies at all. There will be knobs to adjust this, however, allowing folks to crank up the cookie lifetime to whatever they please. I said session data" will permit the creation of session data objects, as well as the manipulation of already-created session data objects. Anonymous must be granted this permission (or sessions would be completely worthless, as they would require users to log in). Dieter replied I disagree with this. Anonynous must only access *his/her* session data and must not access session data of any other Anonymous. You have the session id to ensure this. However, the Zope security model is not strong enough, to express this. Therefore, I think, the core should implement a module that handles this special case outside the current Zope security model. Token obscurity is the best we can manage. It should really not be thought of as security. (But if you came up with a truly secure web identification mechanism that does not require any authentication/client certificate, doesn't rely largely on security through obscurity, and that's completely 100% transparent to any number of end users that may be using any number of stock browsers, I'm sure somebody at RSA would be willing to pay you hundreds of millions of dollars. I'd even give you a couple thousand! :-) How do you propose that we recognize one 'Anonymous User' from another? What do you have session id's for? Session tokens, AFAICT, cannot be secured. They can only be obfuscated, which mitigates the risk that they will be guessed. However, there's no way to completely secure them, no matter how many MD5 hashing algorithms you run on them. If a session token is stolen, that's the key that the "attacker" needs to visit the website "as you". I've addressed this in the implementation by giving the session token a random element, and this mitigates a guessing attack, but not a theft attack. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: CoreSessionTracking proposal
I just read the CoreSessionTracking proposal. Great... I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? Because it's a browser id, not a session id. This terminology may change in later revisions of the code I've come up with, but this is the basic idea. This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. Not if you want to associate a session with a browser across a long period of time. For example, if you wish to maintain a long-lived "wish list" of items in session storage without requiring a user to log in. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. I do not see any reason why a site should be able to track my activity over a longer period of time -- at least no without my explicit consent. The cookie lifetime is configurable, so this is up to the site manager or developer. This is not a problem endemic to Zope or the core session tracking proposal, but to the configuration imposed by the developer or site manager. Lots of people don't mind long-lived cookies, and it's not realistic to limit the functionality of the system based on something that's out of our scope of influence. If you choose not to visit sites that provide long-lived cookies, then perhaps that site's session manager will choose to reduce the cookie lifetime. Security: * I do not think "Annonymous" should have the permission "Add Session Data Objects". Session handling should be transparent, including allocation of a session data object. The use case description that mentions "add session data objects" is incorrect. That permission will not exist. The overall permission "Access session data" will permit the creation of session data objects, as well as the manipulation of already-created session data objects. Anonymous must be granted this permission (or sessions would be completely worthless, as they would require users to log in). * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. How do you propose that we recognize one 'Anonymous User' from another? Sessions may contain confident information that must not be revealed to other users. Anonymous session data should not contain confidential information. This is what data storage associated with an authenticated user is for. However, the risk of information release is mitigated somewhat (but not much) by the fact that session ids will have a random element. Additionally, the "access session data" permission can be withheld from users who have the rights to create DTML or other TTW methods, thus disallowing them to manipulate a visitor's session data from this code. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). This is not possible without authentication. The point of sessions is to allow the developer to associate a namespace across multiple visits by an anonymous user. Requiring a user to authenticate before using sessions defeats the purpose. Consistency: * sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking The identifier is configurable. It should probably start with an underscore to be recognizable as a URL-inlined attribute, but this is up for debate. The ids used within the proposal are only suggestions. * how is it possible to have nested "Session ID Managers" (necessary for delegation) with "getZopeSessionID" a singleton? As I understand it, the "singleton" property prevents any child to reimplement the method. I must be wrong with this assumption. I probably misused the term "singleton". Thanks! -C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
