Re: userpassword encode/hash

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

At 10:30 AM 9/1/2004, John Wagner wrote:
>I do recall the RFC now, but also note that whole section falls under
>the SHOULD, not the MUST heading.

You confuse a recommendation to implementations to support a feature
as a recommendation on how that feature is to be implemented if
supported.  Sorry, no.  If an implementation chooses (as recommended)
to support userPassword, then it ought to implement it in full
accordance of its technical specification.  That technical
specification is quite explicit, both in syntax and semantics,
in what values userPassword is to take.  Also, it should be noted
that beyond this requirement, there is the general requirements
placed on all user application values.  Servers are not suppose to
muck with user application values, to do so violates the basic user
data model of the directory [X.501,draft-ietf-ldapbis-models-xx.txt].
(Note that servers MUST act in accordance with X.500 [RFC 2251].)

>In our environment we would basically be walked out the door if we
>suggested that userpassword be kept in un-encrypted form besides
>failing every type of audit we must go through! ;-)  Do others who keep true passwords in userpassword keep them un-encrypted?

Yes.  In fact, full functionality of slapd(8) requires they be in
clear text.

But, more to the point, regardless of what value you are going
to store, you need agreement between all of its producers and consumers
as to its syntax and semantics to ensure interoperability.  For
userPassword, Section 5.36 is the agreement.  For authPassword
(which does allow for storage of hashed passwords), RFC 3112 is
that agreement.  And, if those are inadequate, you certainly can
design new schema.

The problem with the experimental {SCHEME} stuff is that, besides
being not consistent with standard track specifications, there is
no agreement as to which {SCHEME}s applications are to support.
This has been a major source of interoperability problems between
applications which participate in this experiment.

>If there is other interest I might consider doing a plug-in.  But for
>now it wouldn't be worth the effort for me as it is just easier to add
>in my 15-20 lines of code into modify.c.

IIRC, we've rejected similar proposals (for integrated userPassword
mucking).  I see reason why we would reject this proposal as well.
Which is why I suggested going to contrib plugin route (as here
we're more liberal in what we accept).

>There are a couple of other
>things I'd rather focus on first - such as a true audit log (which
>would be another "security" requirement) and also something I just
>about have completed in changing multimaster to be turned on by a
>config file instead of having to compile separate slapd for masters
>and consumers.
>
>Thanks,
>John
>
>On Tue, 31 Aug 2004 10:26:03 -0700, Kurt D. Zeilenga <kurt@openldap.org> wrote:
>> At 09:32 AM 8/31/2004, John Wagner wrote:
>> >I've been wonder if you all could give me a brief on why OpenLDAP
>> >slapd doesn't automatically encode/hash userpasswords -
>> 
>> A short answer lies in the first sentence of Section 5.36
>> of RFC 2256, as well as last sentence of Section 6.1 of
>> draft-ietf-ldapbis-models-xx.txt.  The long answer lies
>> in the archives (of this list, the software list, and
>> various LDAP/X.500 standardization lists).
>> 
>> >or at least have the option?
>> 
>> We've provided a plugin API would allows those who want to
>> violate the standards to do so. :-)
>> 
>> >I've wrote a few modifcations the slapd including a simple
>> >patch/modification to modify.c that will encode/hash the userpassword
>> >attribute when a mod is done.  It also checks to make sure that it
>> >isn't already encoded if it is it doesn't encode again.
>> >Any interest?
>> 
>> Personally, no.  But I likely wouldn't object to inclusion
>> of a contribWare plugin which did such if it included an
>> appropriate README detailing how it violates the standards
>> and the issues that might cause to those choosing to deploy
>> the plugin.
>> 
>> Kurt
>> 
>> 
>
>
>-- 
>Thanks,
>John