[
http://issues.apache.org/jira/browse/DIREVE-296?page=comments#action_12362357 ]
Stefan Zoerner commented on DIREVE-296:
---------------------------------------
Here is the update you asked for:
The current 0.9.4 snapshot already contains an partial implementation of the
requirements described in this issue.
If a user entry contains a userpassword attribute with a digested (e.g. MD5)
value, authentication is still possible (password in clear). This is due to
changes in class org.apache.ldap.server.authn.SimpleAuthenticator made in
November 2005.
To be more concrete, if you add an entry like this (password is "beekeeper")
dn: cn=Tori Amos,dc=example,dc=com
objectclass: top
objectclass: person
sn: Amos
cn: Tori Amos
userpassword: {SHA}Bv4hld5bnIbFqp9CAnBEzQ/9ceo=
The following works (Tori binds successfully):
$ ldapsearch -D "cn=Tori Amos,dc=example,dc=com" -w beekeeper -p 10389 -b
"dc=example,dc=com" -s one "(objectclass=*)"
Only those algorithms which are supported by java.security.MessageDigest work
properly. We have a contribution for a more extensible solution by Jacob S.
Barrett, see DIRJANUS-28 for details. It is not included in the current code.
Currently it is necessary to store the userpassword attribute "encrypted" on
your own, in the form "{algorithm}BASE64VALUE". Some tools offer support for
that (Softerra, JXplorer, ...). This is the missing part of the requirement. It
would be nice to have a configurable interceptor which stores userpassword
values in a digested manner automatically (not everyone will choose this
option, because some authentication methods forbid storing password one way
encrypted).
Its up to you to decide whether the functionality described above (storing
hashed passwords is allowed and simple bind acknowledges them) and already
implemented is sufficient for a 1.0 as a bare minimum.
> 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: Stefan Zoerner
> Priority: Blocker
>
> 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
