[Zope] CoreSessionTracking-based LoginMethod for LoginManager

[Chris McDonough]

Andy Gimblett wrote:
> 
> > It's as secure as the key shared by the login method and the object in
> > the session data.
> 
> ie, choose it well. :-)

Yup, and don't let it get out.
 
> > Yeah, although it's really the same thing in this case.
> > Encrypting the user info with a shared key and storing it in a
> > cookie isn't really all that much less secure that storing the user
> > info in a session data object.  Although I guess it could be argued
> 
> Yes, I see that - but I didn't think any of the existing cookie-based
> products even did that... I thought they just encoded a concatenation
> of username and password in base64 (which is trivially decodable) and
> stored that. Was I not looking hard enough?

I'm not sure, I haven't looked lately either...
 
> > > Of course, I'm assuming that CST includes checks to guard against
> > > cookie-hijacking. :-)
> >
> > Um... maybe.  What kind of checks did you have in mind?  ;-)
> 
> :-) Hmmm, let's see... OK, I've never done this myself but I remember
> reading that it's a good idea to do this kind of thing to your cookie
> values to ensure they're not hijacked:
> 
> 1. Start with the data you want to store
> 2. Append identifying information, eg the IPs of the client and
>    server, and the current date/time.
> 3. Make a digest of this plus a secret string which only you know,
>    and append that as a fingerprint.

This is a reasonable thing for some applications, I think, yes...
However, there was some discussion on the list a while back about this,
and it was decided that the IP detection in particular wasn't really
feasible as a general solution due to problems caused by folks who have
very dynamic IP addresses (ala folks behind load-balancing NAT boxes).

Even more generally, it was decided that session tracking was not to be
used for data that was very meaningful from a security perspective. 
Unfortunately, that's what you're trying to do. ;-)
 
> Then when you interpret the cookie, check that the fingerprint is as
> you'd expect (ie the cookie hasn't been interfered with by a man in
> the middle) and then check anything else you want to check (eg the
> IP/date).
> 
> Once you're happy with the fingerprint, you check that the server IP
> is the IP of the host box, that the client IP is good too, and that
> the date/time aren't unreasonably out of date - the idea is to guard
> against re-use of old cookies or cookies from somewhere else. As I
> say, I've never done this but it sounds reasonable in principle.
> 
> Make sense?

Yup, but it's probably not going to be implemented as a general feature
of the sessioning machinery any time soon... I'm not sure if this is
enough to drive you towards abandoning the sessioning machinery and
attempting to use cookies instead, but it might be, sorry!

Thanks!

- C


> 
> -Andy
> 
> --
> Andy Gimblett - Programmer - Frontier Internet Services Limited
> Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/
> Statements made are at all times subject to Frontier's Terms and
> Conditions of Business, which are available upon request.
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )

-- 
Chris McDonough                           Zope Corporation
http://www.zope.org                    http://www.zope.com

""" Killing hundreds of birds with thousands of stones """