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
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
From: "Chris McDonough" <chrism@zope.com>
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.
And they can be spoofed too.
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?
Hi! You are right that sessions might not be the rigth thing to protect really secure stuff, like Extranet access, but I would not want to have anonymous users of a shopping cart application log in with a username and password. These shopping cart applications are where you need both ease of use (which can only be provided by a session) and (at least some) protection. So it is a GOOD THING (TM) to have session ids that are relatively hard to guess. Combined with SSL that seems to be a reasonable thing to do. Joachim
It's probably useful to walk through a real-world example... You develop an application using sessions that is a typical "shopping cart" sort of app, where the cart items are kept in a session data object, and the user needn't be authenticated (in any other way than having a session id) to place items in his cart. At checkout, he needs to jump through a couple of hoops to actually buy the items. Let's say for sake of example that the session ids are one character long. Obviously, they'd be very guessable. So let's say a bad guy comes along and plays around long enough to figure out the sessioning weakness, and he subsequently guesses a couple session ids. He goes into each session he can guess and messes around with the cart items, adding some items to one person's cart, removing some other items from another person's cart, etc. This is annoying, of course, but it's not too bad yet. The bad guy can't actually *buy* anything as another person. For that level of access, you'd want to make sure that the user provides a validation; a username-password combo or a credit card number. You'd want to explicitly make sure that he couldn't a) get the person's address, phone number or (god forbid) credit card number as a result of getting a session id by sniffing it or guessing it. The article that Frank sent over deals with apps that are built around session ids as sort of a psuedo authentication credential. We're going to recommend in Zope 2.5 sessioning docs that you don't do that. Sensitive information should be protected in ways other than just with a session id. So given that we deem that it's bad design to keep sensitive info around in sessions like credit card numbers, phone numbers, addresses, etc, and given that session ids are even now currently pretty tough to casually guess (19 characters, 8 of which are randomly generated), are there mitigatable risks which have a solution that doesn't depend on unchanging IP addresses that I'm overlooking? - C ----- Original Message ----- From: "Joachim Werner" <joe@iuveno-net.de> To: "Chris McDonough" <chrism@zope.com>; <zope@zope.org>; "Frank Tegtmeyer" <fte@lightwerk.com> Sent: Monday, November 26, 2001 8:49 PM Subject: Re: [Zope] CoreSessionTracking: Brute-Forcing Web Application Session IDs
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?
Hi!
You are right that sessions might not be the rigth thing to protect really secure stuff, like Extranet access, but I would not want to have anonymous users of a shopping cart application log in with a username and password. These shopping cart applications are where you need both ease of use (which can only be provided by a session) and (at least some) protection. So it is a GOOD THING (TM) to have session ids that are relatively hard to guess. Combined with SSL that seems to be a reasonable thing to do.
Joachim
_______________________________________________ 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 )
participants (4)
-
Chris McDonough -
Frank Tegtmeyer -
Joachim Werner -
Lennart Regebro