> Is this intentional, perhaps because MD5-challenge > is considered better? (though it requires the > server to store a password-equivalent, whereas > sending password in-the-clear allows the > server to store hashes of passwords) I have not looked at the MD5 challenge, but I did write the original HTTP digest scheme, we had these arguments ad nauseam and lost, so HTTP throws out base 64 passwords... It makes little sense to attempt to secure a network protocol with a technique that is vulnerable to a network attack. If your network is secure enough to send the password enclair then you do not need IPSEC. There is no way you can have secure password storage and network security unless you go to public key. The one way encrypted password technique adds some security but not really very much. The password file will always be vulnerable to a dictionary attack, a salt only causes minor inconvenience at this point. So the real tradeoff is a choice between strong on the wire protection and depending on the security of the password file and zero security on the wire and depending a heck of a lot but not quite so much on the security of the password file. The digest scheme has one other feature that is worth making an effort to preserve, the domain is used to salt the hash. This means that if a password file is compromised it does not compromise any zone other than the one that compilled it even though we know that the users will share all their passwords on all their accounts. Phill
Attachment:
smime.p7s
Description: S/MIME cryptographic signature