Re: userpassword encode/hash

[John Wagner <azentropy@gmail.com>]

Hi,

Thanks for the info.

I do recall the RFC now, but also note that whole section falls under
the SHOULD, not the MUST heading.  Which for those of you who don't
know is what is recommended (According to the definition in RFC
2119)...  But I'm sure you all have had that discussion before...

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?

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.  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