Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <2026859351.1130454776716.JavaMail.jira@ajax.apache.org>
Date: Fri, 28 Oct 2005 01:12:56 +0200 (CEST)
From: "Stefan Zoerner (JIRA)" <directory-dev@incubator.apache.org>
To: dev@directory.apache.org
Subject: [jira] Commented: (DIREVE-296) Storing user passwords other than in
 clear
In-Reply-To: <1238746614.1130364775481.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DIREVE-296?page=comments#action_12356150 ] 

Stefan Zoerner commented on DIREVE-296:
---------------------------------------

Consider to implement RFC 3112 ("LDAP Authentication Password Schema"), http://www.faqs.org/rfcs/rfc3112.html
(Thanks to Alex for the hint)

> Storing user passwords other than in clear
> ------------------------------------------
>
>          Key: DIREVE-296
>          URL: http://issues.apache.org/jira/browse/DIREVE-296
>      Project: Directory Server
>         Type: New Feature
>     Reporter: Stefan Zoerner
>     Assignee: Alex Karasulu
>     Priority: Minor

>
> Because the admin user is allowed to see everything, I suggest to store the attribute values for user password other than in clear. I nice solution would be to make this configurable (other server products allow comparable functionality):
> * Configure a hash function to use for password storage (e.g. MD5, SSHA, ...)
> * Allow clients to store the value as a hashed value on their own as well (calculated with a function other than the configured one, if they like)
> * Enable simple bind with value in clear text (hash value calculated within the server and compared against the stored value)
> * Still allow clear passwords, because some authentication mechanisms need this (e.g. DIGEST-MD5)
> Hashed values does not add that much security, but at least is is harder for admin to catch a password and commit it to his/her memory.
> Some products even allow to encrypt the password (two-way), but I think the features above should do for the first run.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira