Re: Incorporating md5-BSD-style passwd-hash in openldap (fwd)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:04 PM 5/3/01, Paulo Matos wrote:
>        After doing this you'll be able to authenticate on ldap, however
>you're using crypt(3) from your system, which might not support
>md5-BSD-style hashed passwords, and this is the main reason why openldap
>team (correct me if I'm wrong) adopted as a future path only to support
>openssl's hash algorithms.

Support for crypt(3) was intended to provide a convenient
means for migrating from /etc/password managed secrets
to LDAP managed secrets.  Hence, the crypt(3) was intended
to be the host crypt(3).  OpenSSL, in my opinion, should
not be providing a replacement crypt(3) as this just
interferes with applications trying to support passwords
in the host format.  It also operates much faster than the
host crypt(3) which is not a good thing for this usage.
While on some systems you might be able to reorder the
libraries so that the host crypt(3) is used, this is not
always possible.  Oh well.

At this point, there must be a half dozen or so new userPassword
schemes that certain folks want.  There seems everyone has a
better scheme to use.   While supporting new schemes for migration
to LDAP makes some sense, one you have migrated to LDAP it really
shouldn't matter (as applications should use bind to authenticate
to the directory).  And for applications which do make use of
userPassword values, they likely either expect the password to
be clear text (per RFC 2256) or only recognize a limited set of
schemes.  Crypt(3) based mechanisms are inherently host specific
and hence should never be exposed to applications. 

As far as the future of userPassword schemes, I am not sure it
makes sense to add lots of new schemes.  However, for now,
we're still reviewing such additions on a case by case basis.

I will make a couple of additional notes.  We will soon to slapd
such that SASL password based mechanisms (PLAIN,CRAM,DIGEST,etc.)
can use the cleartext userPassword as the authentication secret.
Secondly, we need to migrate all hashed password to the new
authPassword attribute type (which should be published as an
RFC soon) [designed specifically to support hashed passwords].

Kurt