Re: authmeth: password issues

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Alexey Melnikov writes:
>Kurt D. Zeilenga wrote:
>> At 01:32 PM 3/14/2004, Hallvard B Furuseth wrote:
>> 
>>> I'd like to see a section like the following in Authmeth, to help people
>>> decide which authentication methods to support and what password
>>> security to expect.
>> 
>> Are you trying to help implementor to decide which mechanisms
>> to support, or help deployers to decide which mechanisms to
>> use?  I gather the latter.

Yes.  Well, developers could put some of it in documentation, or
server management tools and the like, of course.

>> I would rather this focus more on the former (as our primary
>> audience is implementors of LDAP).

Perhaps I should have made it a security consideration.  Plenty
of info for deployers there.

>> In particular, it could
>> note that while DIGEST-MD5 is specifically designed to allow
>> storage of a realm-specific but password-equivalent hash of
>> the password.

That fits in [DIGEST-MD5] as Alexey suggests, but I think it gets too
technical about DIGEST-MD5 for the LDAP spec: It would have to explain
what a DIGEST-MD5 realm is first, or depend on the reader to already
know it.

>> Servers implementing simple DN/password mechanism
>> in addition to DIGEST-MD5, have three basic choices:
>>        1) use the DIGEST-MD5 hash to verify the simple password;
>>        2) store the actual password: generating the DIGEST-MD5
>>        hash as needed, using it directly for simple password; or
>>        3) store both the DIGEST-MD5 hash and a separate hash
>>        of the password for use in verifying the simple password.
>> 
>> It might be useful to briefly describe the trade-offs.
>> 
>> 1) doesn't work to well if you also need to support
>> a mechanism that require another hash of the password, but
>> if you're only supporting DIGEST-MD5 and simple (and PLAIN),
>> 1) seems better than 2).
>> 
>> 2) is appropriate where a server needs to support multiple
>> authentication mechanisms which either require knowledge
>> of the password, or differing hashes of the password.

Only if it is deemed acceptable to store the actual password anywhere
at all, and the LDAP server is secured sufficiently to be such a place.

>> 3) doesn't scale well to multiple mechanisms...

I don't see why.  The 'multiple mechanisms' are just two currently.

>> only is as strong as weakest hash,

True if the hash, or part of it, is available to outsiders.
And the same if true of (2), which uses a _very_ weak hash:-)

>> but even less due to added complexity.

Can be a problem.  Can be insignificant.

> Kurt, I will point out that what you've written is not specific to LDAP. 
> So it might be better if this is incorporated into DIGEST-MD5 itself.

Sounds fine for DIGEST-MD5.  I still like a section about the trade-offs
between LDAP password mechanisms for the LDAP spec.  I'd be happy if
anyone could cut down my text, though:-)

>> One of the reasons for incorporating SASL into LDAP is that
>> if major new attacks are found with DIGEST-MD5, it can easily
>> be replaced.  Hence, I generally think 2) is the best
>> implementation approach.

Won't happen at our site.  We don't want to store plaintext passwords
anywhere.

>>>  The server administrator will need the plaintext of all the server's
>>>  DIGEST-MD5 passwords in order to generate a new set of secret
>>>  DIGEST-MD5 password hashes, or all users with passwords unknown to
>>>  the administrator will need new passwords so one can generate new
>>>  hashes.
>> 
>> Note that the server can obtain the user's password by
>> forcing use of simple bind until the user's entry in
>> the new database is prepared, using the old database
>> for verification of the simple bind used prepare the
>> entry in the new database.  (The old database should
>> not be used for DIGEST-MD5 for obvious reasons.)
>> Where a a server supports realm transition, the
>> administrator just needs to tell the supporting server
>> to undertake the transition.

Very nice, but it also gives me the creeps...  *If* one uses DIGEST-MD5
partly because one is afraid users will contact rogue servers, and
because DIGEST-MD5 does not reveal the password to the server, then one
should absolutely not teach users to 'just use another mechanism if the
server reject DIGEST-MD5'.  So while this would be a nice suggestion to
put somewhere (probably DIGEST-MD5), it should be with a big caveat.

Anyway, my text should have been,

   The server must switch to a new DIGEST-MD5 "realm", so old hashes
   become useless.  To generate new, secret DIGEST-MD5 password hashes,
   the plaintexts of the passwords will be needed.

...maybe plus something of your solution above.

-- 
Hallvard