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

[Jeff Costlow <j.costlow@f5.com>]

I submitted a patch sometime ago that would use {MD5_CRYPT} as a password header, and then it generated a salt that starts with $1$ so that crypt(3) would do the right thing whenn generating a password for the user.

http://www.openldap.org/lists/openldap-devel/200103/msg00061.html

This, of course, assumes that whatever crypt the linker found would support md5 style crypts.  I use Linux and freeBSD, which coincidentally happen to have crypt(3)s that work alike and include md5 support.  But if you happen to have an OS  where crypt(3) behaves differently, you would have to make sure that you use the OpenSSL's crypt.  If you didn't, nothing would change from {CRYPT} passwords except the salt would be predictable ("$1").

I, also, would like to have the ability to switch between /etc/passwd and ldap authentication.  That was the main goal of the patch.

-----Original Message-----
From: Paulo Matos [mailto:pjsm@fct.unl.pt]
Sent: Friday, May 04, 2001 8:22 AM
To: Kurt D. Zeilenga
Cc: openldap-devel@OpenLDAP.org
Subject: Re: Incorporating md5-BSD-style passwd-hash in openldap


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 the main issue is concerning the password generation. We could
even use {crypt}, but at least we could choose which type of salt
did we want. 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. The issue could be solved by some additional
configuration?

	But I can understand that is not easy to support all kind of
crypt/password-hash variants. However, as in Linux, Free BSD and a lot of
BSD-based unix's this kind of password-hash is being widely used, so it
would be IMHO a matter to reflect.

Kurt> While supporting new schemes for migration
Kurt> to LDAP makes some sense, one you have migrated to LDAP it really
Kurt> shouldn't matter (as applications should use bind to authenticate
Kurt> to the directory).  And for applications which do make use of
Kurt> userPassword values, they likely either expect the password to
Kurt> be clear text (per RFC 2256) or only recognize a limited set of
Kurt> schemes.  Crypt(3) based mechanisms are inherently host specific
Kurt> and hence should never be exposed to applications.
	I can understand your side. You're an ldap developer, so your
concerns are in give support while migrate TO ldap and not FROM ldap.

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?

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

	Best regards,

-- 
	Paulo Matos
 ----------------------------------- ----------------------------------
|Sys & Net Admin                    | Serviço de Informática           |
|Faculdade de Ciências e Tecnologia | Tel: +351-21-2941346             |
|Universidade Nova de Lisboa        | Fax: +351-21-2948548             |
|P-2825-114 Caparica                | e-Mail: pjsm@fct.unl.pt          |
 ----------------------------------- ----------------------------------