Re: userPassword question

[Mark Smith <mcs@netscape.com>]

Luke Howard wrote:
> 
> > 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
> 
> Yes, I was reluctant to do this with RFC 2307, but (mainly for
> interoperability with Netscape's Directory Server) I went with prefixing
> hashed values with {crypt} (or {sha} or {md5}) and maintaining the
> userPassword attributes. Nonetheless, using attribute subtypes (see section
> 5.3 of RFC 2307) is probably a good idea at some stage.
> 
> -- Luke

All versions of Netscape Directory Server, from 1.0 on, can optionally
store userPassword values using one of several one-way hash algorithms. 
This was done to meet the needs of our customers.  Some customers
demanded compatibility with existing hashed passwords that they had on
UNIX, NIS, etc.  Others refused to buy a product that ever stored
passwords on the server in the clear or in any way that made them easily
recoverable to someone who obtained access to the directory server
database.  In fact, one of the deficiencies of CRAM-MD5 is that as far
as I can tell it requires that the LDAP server store the password in the
clear (or in a way that allows it to easily recover the clear text
password).  But that's a different topic.

The way our feature works is:

a) If an LDAP client adds a userPassword value (via an add or modify
operation) that it is not hashed, we perform a one-way hash on it before
storing it.  The actual value we store looks like "{crypt}CRYPTED-VALUE"
or "{SHA}SHA-1-VALUE".

b) If a client adds a userPassword value that is already hashed, we just
store it as is.

c) On bind operations, we compare the submitted value (which must be a
clear text password) against all userPassword values -- hashed or
unhashed -- in an entry.

d) On search operations, we return the values as we have stored them. 
There is no way for us to recover the original password, which is a
feature.  This is where compatibility with clients is an issue, but as
someone else pointed out the bind operation should be used to verify
passwords.  Replication to non-Netscape servers (when that becomes
practical) will be a bigger issue.

e) If the server administrator turns off our password hashing feature,
we don't do any of the above.

It is worth noting that when we implemented this, subtypes were not part
of LDAP.  Also, using subtypes will require changes to clients as well,
so I don't see how that really helps with interoperability.

If others think this is a useful feature, I'd be happy to help write an
Internet Draft on the topic.

-- 
Mark Smith
Netscape Communications Corp. / Directory Server Engineering
"Got LDAP?"