[Zope] CoreSessionTracking: Brute-Forcing Web Application Session IDs

[Chris McDonough]

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
>