[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: userPassword question

Perhaps I'm missing something here...
Given that interoperability is important, why couldn't the server
take the responsibility to store the userPassword encrypted and
decrypt upon read, for example.  This preserves the protocol on
the wire for interoperability and allows the userPassword to continue
to be used while not being visible in the directory by anyone 'just browsing'.
Ellen


At 09:10 PM 7/28/98 +0100, Mark Wahl wrote:
>
>> Isn't it a violation of RFC 2256 to have the value of the userPassword
>> attribute encrypted in a way that is visible to the protocol?  Or is my
>> inexperience with LDAP showing?
>
>RFC 2256 states for the userPassword attribute:
>
>   Passwords are stored using an Octet String syntax and are not
>   encrypted. 
>
>An application which wishes to store an encrypted password SHOULD use an
>attribute description distinct from "userPassword".  Reusing userPassword
>for another syntax without preserving its semantics would break 
>interoperability.  One possible approach is to define a new attribute
>type for each encryption mechanism, e.g. unixEncryptedPassword and 
>lanManEncryptedPassword.  However, this approach would mean that an
application
>could not set a password even if it was protected by an TLS connection.  
>Another approach is to define an attribute subtype from userpassword, either
>with a different type name or using an option, e.g.,
userPassword;crypt-lanman
>and userPassword;crypt-unix.  The "crypt" option would need to be 
>defined by an standards-track RFC to specify the desired behavior on a 
>modification, e.g. is each option treated independently, or does the server
>itself ensure that correct password hashes are generated?
>
>Mark Wahl, Directory Product Architect
>Innosoft International Inc.
>