Dave Cridland wrote:
> On Tue Sep 11 11:55:35 2007, Jonathan Chayce Dickinson
wrote:
>> Interesting because most clients used Digest-MD5,
so what do we use now?
>> Cram-MD5? Or is there some other newfangled method
out there?
>>
>>
> DIGEST-MD5 is still more secure than CRAM-MD5, and this
won't change
> because of that draft.
I strongly agree. Despite its imperfections, RFC 3920bis
should continue
recommending and requiring DIGEST-MD5 until something better
has been
adopted by the IETF.
Furthermore I disagree with the following "problem with
the DIGEST-MD5
mechanism" included in the Internet-Draft:
"Implementations may chose to store inner hashes
instead of clear text
passwords. While this has some useful properties, such as
compromise of
an authentication database on one server does not
automatically
compromise an authentication database with the same username
and
password on other servers, in practice this was rarely done.
Firstly,
the inner hash is not compatible with commonly deployed Unix
password
databases. Secondly, change of a username invalidates the
corresponding
inner hash."
In practice inner hashes may be stored relatively rarely,
however that
does not necessarily make the optional feature into a
"problem". It is,
IMHO, a critical security feature that should be employed
whenever
practical. Perhaps RFC 3920bis could encourage this practice
- while
mentioning the potential impracticalities.
Note, a change in the SASL mechanisms supported by future
versions of an
XMPP server is probably a more likely cause of
"invalidating the inner
hash" than changing XMPP usernames (which are generally
fixed).
- Ian
I strongly agree. Despite its imperfections, RFC 3920bis
should continue
recommending and requiring DIGEST-MD5 until something better
has been
adopted by the IETF.
Furthermore I disagree with the following "problem with
the DIGEST-MD5
mechanism" included in the Internet-Draft:
"Implementations may chose to store inner hashes
instead of clear text
passwords. While this has some useful properties, such as
compromise of
an authentication database on one server does not
automatically
compromise an authentication database with the same username
and
password on other servers, in practice this was rarely done.
Firstly,
the inner hash is not compatible with commonly deployed Unix
password
databases. Secondly, change of a username invalidates the
corresponding
inner hash."
In practice inner hashes may be stored relatively rarely,
however that
does not necessarily make the optional feature into a
"problem". It is,
IMHO, a critical security feature that should be employed
whenever
practical. Perhaps RFC 3920bis could encourage this practice
- while
mentioning the potential impracticalities.
Note, a change in the SASL mechanisms supported by future
versions of an
XMPP server is probably a more likely cause of
"invalidating the inner
hash" than changing XMPP usernames (which are generally
fixed).
- Ian