directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Zoerner (JIRA)" <>
Subject [jira] Commented: (DIREVE-296) Storing user passwords other than in clear
Date Tue, 10 Jan 2006 18:08:20 GMT
    [ ] 

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 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

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:
>      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.
> 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:
For more information on JIRA, see:

View raw message