Re: RFC2256: userPassword

[dboreham@netscape.com (David Boreham)]

Paul Leach wrote:

> 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.

Yes, the whole discussion dissapeared in a puff of logic.

Clients shouldn't be granted permission to
read userPassword.
Clients have no business wondering what the
value of userPassword means.
Therefore nobody cares about the format
of the data stored in userPassword.

However, sometimes folk do care:

1. When replication sends the password
information from one server to another.
2. When the contents of a server are
exported to a flat file, and subsequently
imported into another server.
3. When user information, including hashed
password values, is migrated from another
database (e.g. NIS, Oracle).

> > 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.

Until a standard is defined, yes.

> 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.

Indeed. There's tension between the desire to
make the hash expensive to compute (to thwart
key-space search), and cheap to compute 
(to support high throughput authentication
services).