[Zope-dev] Re: CoreSessionTracking proposal

[Chris McDonough]

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