[dev] gollem authentification via Horde

[Jon Parise]

On Wed, Jul 04, 2001 at 04:09:49PM -0500, Brent J. Nordquist wrote:

> > The problem is holding onto the login credentials once the user
> > has been successfully authenticated
> > [...]
> > The problem arises when we look at applications like IMP or
> > Gollem.  Those applications require the web user to authenticate
> > themselves to a particular service (IMAP, FTP)
> 
> Sure.  But don't we already do that today (store the IMAP user and
> password for later use)?  (Because each page refresh potentially may need
> to reopen a new IMAP connection... a persistent IMAP connection isn't kept
> open?)
 
Yes, we do ($imp['pass'], for example).  That isn't necessarily
a good thing to promote to the Horde level, however, because it
will then become accessible for all Horde applications and will
maintain more of a persistence than within IMP's session cache.

If a short term implementation is required, however, this same
technique could also be used in Horde (storing the password in
the session based on a known secret key).

Here's some code for everyone's reference (from imp/lib/IMP.php):

    // Storing the password
    Secret::write(Secret::getKey('imp'), trim($HTTP_POST_VARS['pass']))

    // Retrieving the password
    Secret::read(Secret::getKey('imp'), $imp['pass'])

As you can see, the "key" here is the string 'imp'.  Knowing the
string will allow you to unlock with encrypted password string
stored in the session (with the help of the Session class), but
that's the price we pay for preserving the password's
persistence.

-- 
Jon Parise (jon@csh.rit.edu)  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member


>From chuck@horde.org Date: Wed,  4 Jul 2001 18:35:00 -0400
Return-Path: <chuck@horde.org>
Mailing-List: contact dev-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list dev@lists.horde.org
Received: (qmail 4366 invoked from network); 4 Jul 2001 22:37:33 -0000
Received: from 208-59-250-206.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO marina.horde.org) (208.59.250.206)
  by horde.org with SMTP; 4 Jul 2001 22:37:33 -0000
Received: by marina.horde.org (Postfix, from userid 33)
	id 16F3339F3; Wed,  4 Jul 2001 18:35:01 -0400 (EDT)
Received: from 192.168.0.103 ( [192.168.0.103])
	as user chuck@localhost by marina.horde.org with HTTP;
	Wed,  4 Jul 2001 18:35:00 -0400
Message-ID: <994286100.3b439a14ee5c9@marina.horde.org>
Date: Wed,  4 Jul 2001 18:35:00 -0400
From: Chuck Hagenbuch <chuck@horde.org>
To: dev@lists.horde.org
References: <20010704151920.A28459@csh.rit.edu> <Pine.LNX.4.33.0107041547570.5491-100000@kepler.acns.bethel.edu> <20010704183258.A1284@csh.rit.edu>
In-Reply-To: <20010704183258.A1284@csh.rit.edu>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Subject: Re: [dev] gollem authentification via Horde

Quoting Jon Parise <jon@csh.rit.edu>:

> Here's some code for everyone's reference (from imp/lib/IMP.php):
> 
>     // Storing the password
>     Secret::write(Secret::getKey('imp'),
> trim($HTTP_POST_VARS['pass']))
> 
>     // Retrieving the password
>     Secret::read(Secret::getKey('imp'), $imp['pass'])
> 
> As you can see, the "key" here is the string 'imp'.  Knowing the
> string will allow you to unlock with encrypted password string
> stored in the session (with the help of the Session class), but
> that's the price we pay for preserving the password's
> persistence.

Actually, no. 'imp' is the name of the key. The key itself is a random md5 
cookie stored client side, or a known value (which has the security 
implications outlined above) if cookies are disabled.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
Some fallen angels have their good reasons.