What are the potential security impacts of using CRAM-MD5 for Emails, when not using an SSL connection?

Question

Background: My current server-provider tells me it's no problem to store the passwords in plain-text in the database, saying he has to do so because they use CRAM-MD5 for email authentication. But something tells me that storing password in a database in plain text might not be the only security issue that comes up here and I'm not even sure if CRAM-MD5 can still be considered as "safe" from a cryptographic point of view. After all, I sure don't want to use something insecure for email traffic.

Whatever feedback you can give me - from a cryptographic point of view - about "using CRAM-MD5 for authentication while talking to an email server without the use of an SSL connection" will be highly appreciated. Thanks in advance.

edit : For an InfoSec point of view, check https://security.stackexchange.com/questions/36117/how-secure-is-using-cram-md5-for-email-authentication-when-not-using-an-ssl-con

Answer 1

CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol.

Among positive things there are to say about CRAM-MD5:

1. The password is not exchanged in clear.
2. The protocol is not vulnerable to replay.
3. HMAC-MD5 stands strong (even though MD5 is broken as a collision-resistant hash); thus if the password was unguessable, CRAM-MD5 would provide strong protection against logging by an adversary using passive wiretapping.
4. The password can be long and contain arbitrary characters as far as the protocol is concerned, making the above if at least feasible.
5. It is conceivable to use an irreversible transformation of the password, rather than the password itself, to perform the protocol (by keeping the output of the first round of each of the two MD5 hashes in HMAC-MD5); thus a server using CRAM-MD5 does not really need to keep the password in clear, nor any mean allowing direct derivation of the password (the excuse reportedly given for "storing password in a database in plain text" likely reflects practice, but is wrong from a strictly cryptographic standpoint).
6. MD5 Rainbow Tables can not help to crack the password from intercepts by passive wiretapping: the challenge defeats that.
7. Implementation is simple.

On the negative side:

1. CRAM-MD5 does not in practice meet its primary objective of keeping the password secret from a passive eavesdropper (e.g. using WireShark), because testing a particular password is fast (it requires a single HMAC-MD5, that is typically 4 MD5 rounds), and passwords chosen by anyone except a few paranoids security-conscious persons are guessable by a password cracker. For example this beast reportedly performs 180 billion MD5 per second, that's perhaps 2³⁵ passwords tested per second, translating to less than 5 minutes on average to crack the strong (44-bit) variant suggested by the obligatory XKCD reference; the weak (28-bit) variant, which is already very much above average password practice, is vulnerable to a script kiddie using John-the-Ripper.
2. CRAM-MD5 authenticates one party to the other, not the other way around; in email practice, the client does not ascertain to which server it connects to receive or send email.
3. Using CRAM-MD5 does not protect the confidentiality or integrity of the data exchanged after login: email can be read by a passive eavesdropper, an active adversary can insert commands in an existing session.

---

In summary: CRAM-MD5 provides strong protection against disclosure of an exceptionally strong password by way of wiretapping, symbolic protection for real-life passwords, and almost no other security functionality. In the context of email service provided by an ISP, some will consider the issue moot: email exchanged in this way (without end-to-end security as provided by e.g. GPG) is insecure in many other ways.