James Turnbull wrote:
But if I can also quote the RFC:
"Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext
attacks, and permits the use of third party authentication servers,
mutual authentication, and optimized reauthentication if a client has
recently authenticated to a server."
All of those points are far more likely to apply to HTTP security than
to SMTP AUTH, which is fairly limited in scope.
The password is encoded but yes essentially plaintext. The server
security doesn't bother me so much - locked down fairly tight.
That's what I meant; the limitation with both is that the server must
have access to the plaintext password.
It's the
transaction that does. Particularly in our SSO environment where that
password might exist for multiple applications of varying risk levels.
Enabling TLS is far more important for transactional security, at which
point, you can use LOGIN or PLAIN just as securely as any of the
challenge methods, which are strictly for use where TLS is not available.
There is an interesting hack in Dovecot that I was thinking of copying
for Qpsmtpd: a pasword scheme definition that includes the local (to
the server) encryption used. For example, {CRYPT}password would mean
that the plaintext password passed in (while TLS was in force) would be
crypt()'d and then compared with what is in the user database (ex.), see
http://wiki.dovecot.org/Authentication
for details.
This allows the plaintext password to be passed from the client inside a
TLS wrapper, and yet be encrypted on disk at all times. This is far
more secure than any of the challenge methods, which require storing the
plaintext password on the server...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
