Re: LDAP Password Policy draft...

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

At 11:41 AM 7/27/2001, Subbu Subramaniam wrote:
>The definition of the pwdInHistory (section 4.2.4) should also include the
>text regarding hashed passwords.

I've haven't examined the proposed text yet, but I would be
very leery about depending any of this specification upon
RFC 2307 hashed passwords.  Besides being experimental, this
feature directly conflicts with the standard track specification
of userPassword [RFC 2256].

>If the client hashes the password before
>sending it over to the server (a recommended method, instead of sending 
>cleartext passwords over the network and storing them as cleartext strings
>on the server as well), the history cannot be verified.

RFC 2307 userPasswords (experimental) and RFC 3112 authPasswords
(informational) should be protected as if they were clear text.
If exposed, they are subject to off-line dictionary attacks.

>To that end, I would also like to see an attribute (say,
>'pwdSupportedSncryptionSchemes') added to the pwdPolicy objectclass, that
>specifies the encryption schemes supported by the server. The clients can 
>then make use of this value to decide which encryption scheme is to be used
>to encrypt the password before sending it over for updates.

Hopefully RFC 3062 becomes more widely adopted so that clients
need not concern themselves with how the directory stores the
password.

>This attribute should be multi-valued,

userPassword is, off course, multi-valued (and so is authPassword).

>each value specifying a supported encryption scheme. 

>This would help protect against clients sending over a password of type
>{MD5}oiwejr98wur98uw, and the server treating this whole string as a
>plaintext password!!

That's exactly what is.  Per RFC 2256, userPassword holds values
which are clear text passwords.


Also, responding to an early portion of this thread, Ludovoc said:
>   However you may want to define 2 different password policies for
>   2 separate attributes with the same scope.

I would suggest that two different policies be held in two separate
subentries.

Kurt