--On Thursday, May 07, 2015 20:20 +0200 Marc Haber
<mh+exim-users@???> wrote:
>> If you're instead willing to use PLAIN and LOGIN
>> authentication, you can run saslauthd (a piece of Cyrus
>> software), or even an IMAP-based authentication, where only
>> the hashed passwords are stored on disk or in a database.
>
> This applies to exim as server. He is using exim as a client,
> which _needs_ the plain-text password on the client side.
As one of the guilty parties for CRAM-MD5 (see RFC 2195), I
don't have a "solution", but can perhaps provide a bit of
perspective and suggestion that might help. At the time we did
that work (about halfway through 1997), the IETF and several
other groups were making a big fuss about passing cleartext
passwords over the Internet. There was also continuing concern
about large cleartext password stores on servers although that
theme had been around for 20 years or so. The problem was
that, while those bodies were willing to say "cleartext
passwords over the net = bad", their proposed solutions were
fairly complex, involving either trusted third party servers
(such as Kerberos authentication and ticket servers) or public
key arrangements that were perceived as hard to set up and that
were, IIR, still encumbered by patents and problematic
licensing.
We were also somewhat concerned about a better-than-nothing
authentication mechanism for places in the world where use of
cryptography was illegal.
So, with full awareness that clients would need passwords in the
clear, we specified CRAM-MD5 as a lightweight mechanism for
keeping those cleartext passwords off the net. It was not an
accident that we specified it for IMAP and POP --where having
the client or user know the cleartext password seemed no worse
than using such a password to log in -- and not for SMTP client
-> SMTP server authentication.
In addition to the present concern about storing a lot of
passwords on an SMTP client, some of us were (and remain) a
little skeptical about the value of strong authentication (with
or without encryption) on a hop-by-hop basis rather that
attaching authentication, integrity checks, and/or encryption to
the message (via S/MIME, OpenPGP, or equivalent). CRAM-MD5 was
never really expected to provide strong security and the spec is
fairly explicit about that.
And _that_ is probably the real answer to the question: these
SMTP client -> SMTP server authentication methods that require
cleartext passwords (or shared secrets generally) to be stored
on the client machines perhaps still have value, but their value
isn't in providing really strong protection (MD5 isn't good
advice 18 years later either). If strong protection is needed,
the right question is probably not "how do I hide those
passwords" but "what techniques can I use that provide two-way
authentication, credentials that do not expose sensitive
information, and protection for potentially-sensitive envelope
or message content information between hosts?" That question
probably has good answers today even if it didn't under the
constraints we faced 18-20 years ago, starting with using
STARTTLS, encrypted tunnels, and reciprocal certificate-checking.
best,
john
