Re: userpassword encode/hash

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

At 02:56 PM 9/1/2004, John Wagner wrote:
>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?

Certainly our password modify (RFC3062) code can be configured in
a manner which violates RFC 2256.  It's hoped folks don't do that.
But, more importantly, its hoped that password modify adoption
will aide in the transition to authPassword and/or other attributes
specifically designed to support hashed passwords (as well as
help end the userPassword {SCHEME} experiment), or at least
aide in the separation of password use (in management and
authentication) and password storage.

My fear in accepting a modify userPassword patch as proposed is
that it would promote further experimentation which problematic
for a number of reasons (which I highlighted in my previous
message).

Kurt