Storing user passwords other than in clear

• Key: DIRSERVER-261
• Type: New Feature
• Status: Closed
• Resolution: Fixed
• Priority: Blocker
• Assignee: Stefan Zoerner
• Reporter: Stefan Zoerner
• Affects Version/s: pre-1.0
• Fix Version/s: 1.0-RC1

Description

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.

Comments

[Stefan Zoerner]

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

[Alex Karasulu]

Any progress on this Stefan. I'd like to have this feature in the 1.0 RC1 so let me know how it's coming along. Thanks!

[Alex Karasulu]

This is very important. I would not put an LDAP server into a production environement if passwords were in the clear even if I did have ACI to protect them. Just not a smart idea.

[Stefan Zoerner]

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.

[Alex Karasulu]

Sounds great Stefan. Congrats on your first feature addition to the server. This is exactly what we're lookiing for in 1.0. Just not to have passwords in the clear stored in the repo is a big plus. I'll be looking to play with this feature within a litle bit. Thanks!!!

[Stefan Zoerner]

How about closing this issue (hence it is blocker) and create a new wish, which only contains the missing functionality?
The latter is only one of the original four list items from this issue missing: To configure an optional password message digest algorithm which is applied on userPassword attribute values at add and modify operations.

[Alex Karasulu]

These issues are related. This one is to complete the functionality on DIREVE-296.

[Alex Karasulu]

Thanks Stefan I will create the new issue for the missing parts of this. Please elaborate on htat issue.

[Stefan Zoerner]

Alex created a new item which describes the missing functionality of this issue: DIRSERVER-289. Therefore I close this one.