[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
stpeter at stpeter.im
Tue Sep 11 20:22:26 UTC 2007
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
>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards