Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: mail@stefan-seelmann.de
In-Reply-To: <AANLkTimYP6KoCWBRK8HMwSHX+ViBHaMJwcM98Beo34Ap@mail.gmail.com>
References: <AANLkTimYP6KoCWBRK8HMwSHX+ViBHaMJwcM98Beo34Ap@mail.gmail.com>
Date: Sun, 31 Oct 2010 10:38:11 +0100
Message-ID: <AANLkTi=xZwhXtKmc+Ca6OBG=bP3z=Jy5h9TFSbXcdux0@mail.gmail.com>
Subject: Re: [ApacheDS] hashing passwords before storing
From: Stefan Seelmann <seelmann@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Kiran,

On Sun, Oct 31, 2010 at 8:49 AM, Kiran Ayyagari <kayyagari@apache.org> wrot=
e:
> =C2=A0hello dev,
>
> =C2=A0Currently we don't have a feature to automatically hash the passwor=
ds before
> =C2=A0storing them, I would like to propose that we should add this featu=
re.
>
> =C2=A0I would like to add a new interceptor to support this feature:
>
> =C2=A0 1. It is easy to enable/disable without adding some more config op=
tions
> =C2=A0 =C2=A0 =C2=A0 to DirectoryService
> =C2=A0 2. We can place at the appropriate position in the interceptor cha=
in so that
> =C2=A0 =C2=A0 =C2=A0 changelog and journals will also have the same passw=
ord as the DIT
>
> =C2=A0We currently support the following hashing algorithms
> =C2=A0 =C2=A0 =C2=A0 =C2=A0SHA, SSHA, MD5, SMD5, Crypt, SHA-2 (256, 384, =
512 along with their
> =C2=A0 =C2=A0 =C2=A0 =C2=A0salted counterparts)
>
> =C2=A0Studio might need to change its 'password change' screen by adding =
an option
> =C2=A0to send the plain text password though the original password is has=
hed.
> =C2=A0(AFAIU currently studio hashes on the client side and sends)
>
> =C2=A0thoughts?

Is this related to the password policies? I think to check the quality
of passwords it is required to send them in plain text, right? In that
case it would be nice to be able to hash the password on the server
side, so +1 form my side.

If we place that interceptor after the KeyDerivationInterceptor it
would also solve the issue that the user password is stored in plain
text when setting up a Kerberos server.

I just wonder if we should have a separate interceptor or if the
server-side hashing should be implemented in the password policy
interceptor.

Kind Regards,
Stefan