CoreSessionTracking proposal
I just read the CoreSessionTracking proposal. 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? This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. * 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. I tend to refuse long living cookies and as sites continue to send cookies on any request, I disable cookies all together. If this means, a site can not be visited, I stop visiting the site. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. 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. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. Sessions may contain confident information that must not be revealed to other users. 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). Consistency: * sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking * 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. Dieter
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
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
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
DISCLAIMER: everything I'm about to say is my understanding based on my discussions with Chris about how to do session management, and does not necessarily reflect the current state of the session management code that he is developing, or what will end up in the Zope core. :) At 09:27 PM 9/30/00 +0200, Dieter Maurer wrote:
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?
It doesn't need to, necessarily. However, since the session data is decoupled from ID management, the browser ID needs to live at least as long as the longest type of session handled by the site.
This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day.
Correct. Of course, if the site *also* contains session objects that have a life on the order of a day, then at least one cookie set by the site must have that longer lifetime. Thus, by setting the browser ID lifetime to at least as long as the longest session, one avoids having multiple cookies, one per session manager.
* I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future.
If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them.
The actual lifetime of a browser ID will be controllable by the Zope site manager. I agree with you, however, in that the default lifetime should be reasonable. Indeed, I would suggest that the default simply be to use cookies with no expiration date, and which therefore only live so long as the user's browser is open, be it minutes or days.
* I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data.
As I understand it, the "Access Session Data" permission gives you the right to call a method that returns you the session data for the current request, but does not give you the right to access arbitrary session data. Thus, one only has permission to see one's own session data.
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).
No such policy is necessary, since access to the session data objects themselves is gated. You can't get to the session object unless you have management rights on the session data manager itself, or if the session data object is for "your" session -- the session for the current REQUEST. Once you have retrieved that session data object, what you can do with it is entirely dependent on what the object is. For example, a shopping cart object might grant Anonymous users access to place or remove items in it. Other types of session data objects might grant permissions to record click-tracking data, but not to view it. Nonetheless, most of these permissions issues are moot under normal circumstances, unless you are granting anonymous users the ability to create DTML or other executable methods in your site. Session data objects are not directly accessible through the web under normal circumstances without management access to the session data manager object.
"Phillip J. Eby" wrote:
Thus, by setting the browser ID lifetime to at least as long as the longest session, one avoids having multiple cookies, one per session manager.
This is a good point and one that I probably didn't make clear in the use cases.. it's entirely possible to have a site with hundreds of session data managers. Each session data manager may implement its own policy as regards session data object expiry the type of session data object(s) it returns, as well as the storage of these session data objects. The point of the "browser id manager" is to handle the requirement to identify visitors between requests on behalf of all the session data managers in the system, as opposed to requiring each data manager to handle this identification. Thus, only one identifer need be used for all the session data managers in a system. However, as prompted by a Digital Creations "jam session", there are going to be changes to the use cases which actually make the "Browser Id Manager" into a "Session Id Manager" which will generate a "session token" that will carry both a "browser id" (meant to semipermanent) *and* a "session key" (meant to exist for the duration of a "session" as bounded by a "global" timeout period). This is purely an implementation detail, driven by the somewhat specious requirement that we allow people to associate a "session" bounded by one session data manager with a "session" bounded by another in the same system. (The implementation is also driven by my reluctance to store session key state related to a browserid inside Zope itself... it could be handled internally, but I've decided to put the "session" state on the client instead, it's easier). This will be an opt-in feature for session data manager implementations, and does not change much of the underlying principle of having a potentially "semipermanent" browser id. Contributed session data managers will be free to ignore the (oft-changing) session key component of the session token, and will be free to implement their own session expiry policies related only to the browser id component of the session token. However, it also means that session tokens (which replace browser ids as a identification value) will be prone to change much more frequently, as a new session token will be constructed every time the "global" session timeout expires, and it will contain both the "browser key" (potentially recycled out of a received token) and a new "session key". This may actually be beneficial (in some twisted, baroque way :-), because it means that people will be less tempted to set the cookie expiry time far into the future, as the cookie will be reset more often.
* I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future.
If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them.
The actual lifetime of a browser ID will be controllable by the Zope site manager. I agree with you, however, in that the default lifetime should be reasonable. Indeed, I would suggest that the default simply be to use cookies with no expiration date, and which therefore only live so long as the user's browser is open, be it minutes or days.
This sounds like a reasonable default.
* I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data.
As I understand it, the "Access Session Data" permission gives you the right to call a method that returns you the session data for the current request, but does not give you the right to access arbitrary session data. Thus, one only has permission to see one's own session data.
This is true. If you can guess (or steal) someone else's session token, however, you will be able to access the site "as that user", though you still will not be able to arbitrarily view session data object contents, only what is shown by the application code. I think Dieter's comments point out that the overarching requirement that sessioning be useful in the context of anonymity is at odds with the desire to lock down access to the data referenced by a session identifier. I will need to spell out very clearly in the user docs that session data not be used to store intensely sensitive information. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
At 10:44 PM 9/30/00 -0400, Chris McDonough wrote:
However, as prompted by a Digital Creations "jam session", there are going to be changes to the use cases which actually make the "Browser Id Manager" into a "Session Id Manager" which will generate a "session token" that will carry both a "browser id" (meant to semipermanent) *and* a "session key" (meant to exist for the duration of a "session" as bounded by a "global" timeout period). This is purely an implementation
Huh? I don't get it. It's still just an opaque key from the POV of the session data managers, right? It doesn't matter how you assign the key, just as long as it's unique. The concept of a "browser id" was purely a *metaphor* on my part to show why you only needed one key, whose lifetime only needed to be as long as the longest session handled by the session data managers. That's also why in the docs I wrote up on the Wiki, I called the ID handler a "session ID manager", not a browser ID manager. As far as I can see, there isn't any need for a *real* browser ID, it was just a metaphor.
detail, driven by the somewhat specious requirement that we allow people to associate a "session" bounded by one session data manager with a "session" bounded by another in the same system. (The implementation is also driven by my reluctance to store session key state related to a browserid inside Zope itself... it could be handled internally, but I've decided to put the "session" state on the client instead, it's easier).
I'm still lost. Reluctance to store what state? Why do you need to store anything? Keep in mind that a session data manager just throws away its record for a given ID when it wants to expire it. If the user "comes back" and still has a session cookie, that particular session data manager will just start a new session with the old key. No harm, no foul. If a specialized session data manager wants to keep permanent records of expired sessions, it can simply move the record somewhere else and/or give it a permanent key when it expires. Or it can give every session a permanent ID, but simply look up active sessions using the session cookie. I assume from the use cases, however, that a permanent record of an expired session is a rarity, not the rule. So it seems wrong to me to add complications just to handle that case. As for associating sessions between two session data managers, why can't the simple session cookie concept handle that? It's only one ID, and so is shared, right? I'm not quite clear on what the requirement is here.
This will be an opt-in feature for session data manager implementations,
Now I'm really lost. What does the feature have to do with the session data managers at all?
token. However, it also means that session tokens (which replace browser ids as a identification value) will be prone to change much more frequently, as a new session token will be constructed every time the "global" session timeout expires, and it will contain both the "browser key" (potentially recycled out of a received token) and a new "session key".
This sounds to me again like the "browser id" concept is being taken too literally. I assumed that the global "session ID" would expire and be reset just as described above. It sounds to me like you're "changing" to what I thought we agreed on in the first place. :)
This may actually be beneficial (in some twisted, baroque way :-), because it means that people will be less tempted to set the cookie expiry time far into the future, as the cookie will be reset more often.
I think you're actually making things more complex than they need to be. It sounds like the misunderstanding probably stems from the part of the SessionIDManager Wiki page that reads: "Session ID's provided by a Session ID Manager never expire. The cookie may expire, or data associated with the session may expire, but the session ID never does. It can be thought of as being like a "browser serial number" that sometimes changes (when a cookie expires, or user reloads a non-session URL in URL mode)." What this means is that there is never any reason to issue a new global session identifier value when one already exists. However, if the cookie which *carries* that global session identifier expires, then one may consider that global session identifier to have expired. What I was trying to emphasize is that *you don't need to know when the 'global' session has expired*. Only session data managers need to know something has expired, and they do it by timeout on their local session data objects, and they don't need any info from the SessionIDManager in order to do that. That's why I described it as the session ID never expiring. The SessionIDManager just issues ID's. It doesn't have to remember them, expire them, or anything else. It *just* gets the current ID or issues a new one if it doesn't exist. That's all. The properties on the SessionIDManager control the cookie expiration, which thus controls the lifetime of the global session token. Is this making more sense now? Don't try to implement a "real" browser ID, there was never intended to be one in the first place. As the Wiki page says, it can be *thought of* as *being like* a browser serial number. It's really just a session ID, like the one you're trying to "add". :)
This is true. If you can guess (or steal) someone else's session token, however, you will be able to access the site "as that user", though you still will not be able to arbitrarily view session data object contents, only what is shown by the application code. I think Dieter's comments point out that the overarching requirement that sessioning be useful in the context of anonymity is at odds with the desire to lock down access to the data referenced by a session identifier. I will need to spell out very clearly in the user docs that session data not be used to store intensely sensitive information.
There are a few things that can also be done to shore up the security. One, of course, is that session ID's should be hard to guess. And, it should be possible to specify to the SessionIDManager that "secure" cookies (HTTPS only) are required.
participants (3)
-
Chris McDonough -
Dieter Maurer -
Phillip J. Eby