Re: RFC2256: userPassword

[Bruce Greenblatt <bgreenblatt@dtasi.com>]

Novell Directory Service has this extremely useful operation "Verify
Password" that is available through its API set.  This allows third party
applications to authenticate users to its service in a way that is
integrated with the directory without acutally have to log in to the
directory on their behalf.  So, the application knows the user's password
for an instant...  Is this type of operation generally useful???

Bruce

At 11:17 AM 6/30/99 -0700, David Boreham wrote:
>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).
>
>
>