RE: RFC2256: userPassword

[Paul Leach <paulle@microsoft.com>]

> -----Original Message-----
> From: dboreham@netscape.com [mailto:dboreham@netscape.com]
> Sent: Wednesday, June 30, 1999 10:28 AM
> To: Paul Leach
> Cc: ietf-ldapext@netscape.com
> Subject: Re: RFC2256: userPassword
> 
> 
> Paul Leach wrote:
> 
> > This has nothing to do with replication, as far as I can 
> see. If I'm a
> > client of LDAP, and I want to check if a user name and 
> password that I have
> > been given go together, then I need to know what hash to 
> use so I can
> > compare with what's stored in the userPassword attribute on 
> that user's
> > account object in the directory. Seems like you are saying that its
> > different for each different vendor.
> 
> No, no, no, no, no, no.
> 
> You don't authenticate by client compare
> of credentials, you authenticate by means
> of the LDAP bind operation. Hence the password
> validation mechanism is obscure to the client.

In which case the userPassword attribute need not be visible to clients at
all. In which case this whole conversation has been bogus. Which is what I
thought all along.

> 
> If for some reason you really want to
> do client-side password validation, 
> it's still possible in our product because
> we decorate the stored hashed value with
> a header which indicates the hash function used.
> Thus multiple hash functions may be
> employed within the same directory service.
> This is useful, for example, when some users
> are migrated from UNIX systems, complete
> with crypt hashes, but other users are
> created new, with stronger SHA or MD5
> hashes.

So, it _is_ different for each different vendor. As percieved by clients.

And, offline parallelizable precomputed dictionary attacks, while vendor
specific, are quite feasible. Which is all I wanted to warn people about
when this started. SHA and MD5 are NOT strong against this kind of attack.

Paul