[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]

Dave Cridland dave at cridland.net
Wed Sep 12 10:20:23 UTC 2007


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:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list