Peter Saint-Andre wrote: > Ian Paterson wrote: >> Kevin Smith wrote: >>> On 11 Sep 2007, at 17:20, Ian Paterson wrote: >>>> Even where TLS is available, SASL PLAIN requires server operators to >>>> keep copies of all users' passwords. This is a serious (and often >>>> unnecessary) security weakness. >>> I'm not sure that's true; the server could hash the password still, >>> both in storage and at the end of the wire. It doesn't help against a >>> compromised server that's still accepting connections, but the >>> passwords don't need to be stored plaintext afaics. >> Yes, sorry everyone who corrected me. That was my silly error (lack of >> sleep). >> >> In real life servers will always be compromised (especially in cases >> where the attacker is the service provider). So SASL PLAIN still >> contains a serious vulnerability that is easily fixed in those cases >> where DIGEST-MD5 is a practical option. > > Except that DIGEST-MD5 is effectively being deprecated by the IETF. Thus > the interest in SCRAM, YAP, and their ilk.
Kurt Zeilenga pointed me to the following text in RFC 4513:
B.2.1. Section 4 ("Required security mechanisms")
- The name/password authentication mechanism (see Section B.2.5
below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as
LDAP's mandatory-to-implement password-based authentication
mechanism. Implementations are encouraged to continue supporting
SASL DIGEST-MD5 [DIGEST-MD5].
Presumably we could have similar text in rfc3920bis.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
