[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: authmeth: password issues

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.

I would rather this focus more on the former (as our primary
audience is implementors of LDAP).  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.  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.

3) doesn't scale well to multiple mechanisms... only is as
strong as weakest hash, but even less due to added complexity.

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.

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