directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: [ApacheDS] hashing passwords before storing
Date Sun, 31 Oct 2010 10:03:51 GMT
On 10/31/10, Stefan Seelmann <seelmann@apache.org> wrote:
> Hi Kiran,
>
> On Sun, Oct 31, 2010 at 8:49 AM, Kiran Ayyagari <kayyagari@apache.org>
> wrote:
>>  hello dev,
>>
>>  Currently we don't have a feature to automatically hash the passwords
>> before
>>  storing them, I would like to propose that we should add this feature.
>>
>>  I would like to add a new interceptor to support this feature:
>>
>>   1. It is easy to enable/disable without adding some more config options
>>       to DirectoryService
>>   2. We can place at the appropriate position in the interceptor chain so
>> that
>>       changelog and journals will also have the same password as the DIT
>>
>>  We currently support the following hashing algorithms
>>        SHA, SSHA, MD5, SMD5, Crypt, SHA-2 (256, 384, 512 along with their
>>        salted counterparts)
>>
>>  Studio might need to change its 'password change' screen by adding an
>> option
>>  to send the plain text password though the original password is hashed.
>>  (AFAIU currently studio hashes on the client side and sends)
>>
>>  thoughts?
>
> 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.
no it is not related to password policy, am thinking of keeping it
separate, this helps to hash
the password before storing even if password policy is disabled.
>
> If we place that interceptor after the KeyDerivationInterceptor it
it *should* be places after KeyDerivationInterceptor (otherwise we
have keys generated
using hashed password)
> would also solve the issue that the user password is stored in plain
> text when setting up a Kerberos server.
>
yes, this is a good thing, (may be we should also add a option in
KeyDerivationInterceptor
to completely delete the password after key generation, this deserves
a separate
discussion IMO)

> I just wonder if we should have a separate interceptor or if the
> server-side hashing should be implemented in the password policy
> interceptor.
I prefer to have a separate interceptor so that this feature can be
independent of
password policy status(enabled/disabled)
OTOH, the existing PasswordPolicyInterceptor is obsolete, it is not
used anywhere
and should be removed (this interceptor only checks while adding a
entry, nothing else).

The current passoword policy related logic is present in
AuthenticationInterceptor and the
associated authenticators and performs checks while doing
add/bind/modify operations.

thanks Stefan

-- 
Kiran Ayyagari

Mime
View raw message