Martin Lambers <marlam@...23...> writes: > If a server uses user/password authentication, then PLAIN is really the > only method that needs to be supported, since nowadays an SMTP session > should be protected by TLS encryption anyway. > > If a server wants to offer an additional user/password authentication > scheme that does not reveal the password even in the absence of TLS > encryption, then it should offer the properly standardized > and documented SCRAM-SHA1. Disadvantage to PLAIN: the server must know > the clear text password; storing a hash is not enough. This means a > larger risk for attacks. That's true for CRAM-MD5, but not for SCRAM-SHA1. SCRAM-SHA1 allows the server to only store a hash, so it is nice. However, that makes it harder to in the future migrate to another mechanism which uses another hash. I would say SCRAM-SHA1 is still better than CRAM-MD5, DIGEST-MD5, and PLAIN though. > For the special case of authentication via TLS client certificates, > method EXTERNAL may be used. Yep. Alas, it is a bit underspecified whether EXTERNAL means TLS-and-client-certs or something else. You need to out-of-band policy agreement about this between client and server. > These three methods are really the only useful ones now, as far as I > can see. GSSAPI and GS2-KRB5 are useful for Kerberos people. There ought to be some checks to make sure GSSAPI/GS2 isn't selected if it is likely that it won't succeed (e.g., no Kerberos tickets available). I thought GNU SASL checked that, but I'm not confident. /Simon
Attachment:
signature.asc
Description: PGP signature