RE: [Zope] CoreSessionTracking-based LoginMethod for LoginManager
It's as secure as the key shared by the login method and the object in the session data.
ie, choose it well. :-)
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?
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. 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? -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.
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 """
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.
I rewrite you 3. as computing as a fingerprint: H(known-string || password). This construction apparently still has some very slight cryptographic weaknesses. Lifted from bugtraq sometime ago: From: Michael Wojcik <Michael.Wojcik@merant.com> Date: Mon, 16 Jul 2001 10:45:48 -0700 Schneier cites a private communication with Bart Preneel (author of RIPE-MAC) on possible weaknesses of the obvious constructions H(known-string || password) H(password || known-string) H(password || known-string || password) H(password-1 || known-string || password-2) and suggests one of the following instead (rewritten as password hashes): H(password-1 || H(password-2 || known-string)) H(password || H(password || known-string)) [ie. pw-1 == pw-2] H(password || pad || known-string || password) [pad pw to full block] The simplest of these, in terms of retrofitting existing systems that use one of the constructions Ishikawa mentions, is H(password || H(password || known-string)) So I'd use that last one instead. Florent Guillaume Nuxeo
participants (3)
-
Andy Gimblett -
Chris McDonough -
Florent Guillaume