Re: Incorporating md5-BSD-style passwd-hash in openldap

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

At 08:21 AM 5/4/01, Paulo Matos wrote:
>On Thu, 3 May 2001, Kurt D. Zeilenga wrote:
>
>Kurt> At 08:04 PM 5/3/01, Paulo Matos wrote:
>Kurt> >        After doing this you'll be able to authenticate on ldap, however
>Kurt> >you're using crypt(3) from your system, which might not support
>Kurt> >md5-BSD-style hashed passwords, and this is the main reason why openldap
>Kurt> >team (correct me if I'm wrong) adopted as a future path only to support
>Kurt> >openssl's hash algorithms.
>Kurt>
>Kurt> Support for crypt(3) was intended to provide a convenient
>Kurt> means for migrating from /etc/password managed secrets
>Kurt> to LDAP managed secrets.  Hence, the crypt(3) was intended
>Kurt> to be the host crypt(3).
>        My purpose was to make things more flexible. The flexibility that
>I'm talking about is the ability to easily switch between ldap
>authentication and /etc/passwd files.

And this requires use of the host crypt(3) not OpenSSL's version.

>        And the main issue is concerning the password generation. We could
>even use {crypt},

We should use {crypt} for this as {crypt} was intended to support
migration from /etc/passwd to LDAP.  Using it to support migration
in the other direction makes good sense.  The current tries to support
this, but it's not an easy problem as crypt(3) is by its vary nature
host OS specific.

> but at least we could choose which type of salt
>did we want.

There are countless variants to the type of salts that are
wanted.


>So in a system where crypt only accepts the tradicional 2
>salt characteres this will work as in a system where the salt can have
>from 0 to 8 salt chars.

We already generate 8 characters of salt for systems.  Unfornately,
that's not good enough for some systems which require special
salt formats.

>The issue could be solved by some additional configuration?

Other than to use adaptive code (such as code which calls
crypt_get_format(3) or like functions) [which is likely a rat
hole], a single configuration option might resolve this.

        crypt-salt-format "%.2s"
        crypt-salt-format "%.8s"        (default)
        crypt-salt-format "_abcd%.4s"
        crypt-salt-format "$1$%.8s"
        ...


>Kurt> As far as the future of userPassword schemes, I am not sure it
>Kurt> makes sense to add lots of new schemes.  However, for now,
>Kurt> we're still reviewing such additions on a case by case basis.
>        So does the md5 BSD based crypt variant as a chance?

More general solutions have a much better chance.

Kurt