On Wed Sep 12 07:46:28 2007, Jonathan Chayce Dickinson wrote:
> Hmm, AFAIK such password protection is a designed feature of
DIGEST-MD5. > To take advantage of the feature, when registering a
new account a user > must provide their DIGEST-MD5 inner password
hash instead of their
password.
Which brings you round to square one. Server sends salt, client
sends
MD5(salt+password). I.e. server also needs password to do the exact
same
operation to check for equality, which isn't the best. What we
really need
is a static and dynamic salt, one that never changes and one that
changes
for each login, thus: MD5(salt1+MD5(salt2+password)). This means
that each
user in the database can have a different salt (protecting users in
the case
of a compromised database), and the digest can be different each
time for
the same password (protecting users from a replay attack).
I really recommend you read the specifications before making comments
like this. You seem to be describing CRAM-MD5, then trying to
describe DIGEST-MD5, and then thinking there's replay attacks in
both, whereas there aren't in either.
If the server needs to enforce password policies, then it does of
course need the password. But only with CRAM is there a need to store
it. (Even with those daft policies that insist you cycle through 28
passwords every two weeks).
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
