So many Davids! But the premise in Chadwick's original message was:
the attached document contains an analysis of the alternative ways of
handling
passwords, both storing them in the DSA and transferring them between
DUA and
DSA in the bind and compare operations.
Our analysis reveals that an optimal choice is the one proposed back
in 1990 ...
This entire discussion seems like it should have taken place in 1990.
It's 2009 now; just use PKI-based client-authenticated TLS for both
user
authentication and session protection and be done with it. The
problem
with "unless SSL is used" is that regardless of how strong the
authentication method is (challenge-response PKI, time-based OTP, SASL
SCRAM, ...), if there is no session protection, then the adversary can
just hijack the connection after authentication and do whatever he
wants
to the DSA. As with http://riosec.com/files/gate-bypass.jpg, there's
little point in putting strong authentication on an unprotected
channel.
But given that we're pretending to live in 1990, users don't have
asymmetric private keys and thus are stuck with passwords, and SSL
isn't
used, so let's try to make weak bypassable authentication a smidge
less
weak. Salted hashing is one way to prevent the DSA administrator from
becoming an adversary against other weak systems, such as the user's
gmail account.
