Relying on IP addresses to encrypt communication of a session id is problematic. It's almost impossible to rely on a visitor's IP address being the same from request to request in the face of proxy server banks like the ones AOL uses. Also, I actually think it's a more effective defense to not rely on a session id to protect data. There was lots of discussion about this when CST was in its infancy, and the decision was to recommend that folks not use sessioning to try to protect sensitive data. The shared-key encryption of a sessionid if IP addresses are not used in the hash seem like only a step above pig latin. Instead if you need to do something sensitive, use a username/password combination. Does this seem reasonable? ----- Original Message ----- From: "Frank Tegtmeyer" <fte@lightwerk.com> To: <zope@zope.org> Sent: Sunday, November 25, 2001 3:18 AM Subject: [Zope] CoreSessionTracking: Brute-Forcing Web Application Session IDs
The following article also applies to CoreSessionTracking. CST uses a timestamp and a value generated by the rhandom module.
While this is sufficient to avoid collisions it's not enough to defend against brute force attacks like the ones describe in the appended message.
Perhaps CoreSessionTracking should be switched to an algorithm that was mentioned by Florent Guillaume (Nuxeo):
--------------------------------------------------------------------
From: Florent Guillaume <fg@nuxeo.com> Subject: Re: [Zope] CoreSessionTracking-based LoginMethod for LoginManager Date: 15 Aug 2001 17:07:11 GMT
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 --------------------------------------------------------------------
The needed "secret" could be established by some means during the installation of CoreSessionTracking without even bothering the administrator.
Regards, Frank
---------------------------------------------------------------------- ----------
-- CTO fte@Lightwerk.com http://www.Lightwerk.com/ Fax: +49-2434-80 07 94 Phone: +49-2434-80 07 81 Lightwerk GmbH * An der Kull 11 * 41844 Wegberg * Germany