[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: userpassword encode/hash
On Wed, 01 Sep 2004 12:27:06 -0700, Howard Chu <hyc@symas.com> wrote:
> John Wagner wrote:
>
> >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?
> >
> >
> >
> We use the PasswordModify extended operation. slapd automatically hashes
> passwords that are set using this op.
I'm not familar with PasswordModify but sounds like it too is not
following the RFC if it an encrypted string is being stored in
userPassword... no?
Unfortunately we have about a dozen apps of all sorts - some homegrown
some canned apps - that have the ability to write passwords (most add
new users) so having them change methods isn't desirable or probably
even fessible.
>
> >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.
> >
> I don't see any value in breaking LDAP Modify, plugin or no.
I think I was misunderstood here. By saying "it is just easier to add
in my ..." I meant for me to do it myself - not that those lines
should be added in. If there isn't outside interest there is no
reason to do a plugin - I can just re-add in the code myself when new
versions come out.
>
> > 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)
> >
> We have an auditlog implemented, will be adding it to CVS HEAD soon. It
> currently logs only write ops. For true security audit purposes it needs
> to also be able to log all other operations. I suspect I'll be rewriting
> this as an overlay.
Great to hear. Look forward to seeing it.
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
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>
>
--
Thanks,
John