How secure is using CRAM-MD5 for email authentication, 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. My brain disagrees. But something tells me that storing passwords in a database in plain text format might not be the only security issue that comes up here and I'm not even sure if CRAM-MD5 can still be considered to be "secure" nowadays.

Whatever feedback you can give me - from an InfoSec 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 a cryptographic point of view, check https://crypto.stackexchange.com/questions/8391/what-are-the-potential-security-impacts-of-using-cram-md5-for-emails-when-not-u

Answer 1

CRAM-MD5 requires that the server knows the actual password, not just some image of the password by a hash function. So if the server has to support HMAC-MD5, it has to store the password in plaintext. (The server can encrypt the password, but since it also has to know the encryption key, that doesn't help.)

CRAM-MD5 was designed to avoid having the password transit in cleartext. It gives some amount of protection against a passive attacker. If the attacker can eavesdrop on the communication but not inject messages, then all she gets is a challenge C and the value HMAC-MD5(P, C) where P is the password. There is no better method to find the password from this information by brute force. Brute force is however a concern with passwords: at least a slow function should be used, and exposing the hash should be avoided anyway and should be treated as a compromise.

Instead of a human-chosen, memorable password, the “password” (more precisely a shared secret) stored on the server could be a slow hash of the human password, as noted by Adnan. This would preclude brute-force attacks from the MD5 hash, so it would provide better security against passive attackers. (However, anybody who does this is using non-standard tools, and is presumably serious enough about security to use SSL.) CRAM-MD5 only authenticates the authentication step and not the rest of the session. So an active attacker who is able to impersonate the client can let the authentication happen, then cut off the client (or send it modified data) and send his own commands in the session. Specifically, the attacker has to be able to receive TCP packets intended for the client. Alternatively, the attacker has to be able to receive TCP packets intended for the server, or send fake DNS responses that cause the client to talk to the attacker instead of the server; such an attacker acts as a relay between the client and the server during the authentication phase, then can keep talking to the server. None of these attacks involve a compromise of the password, by the way, other than through brute force as above.

Using CRAM-MD5 over SSL would solve this authentication problem. SSL provides a secure session (i.e. the participants can't change during the session), and authenticates the server to the client (assuming the user won't blindly accept an invalid certificate). CRAM-MD5 brings the third part of the authentication problem: authenticating the client with the server.

CRAM-MD5 over SSL is fine if the password is a long enough randomly-generated string — long enough to resist brute force. If the password is a randomly-generated one, there is no reason not to store it in plaintext on the server, it's just a key. CRAM-MD5 is bad if the password is one that a human can remember, because most human passwords can be cracked by brute force and are valuable beyond that one server as they are often reused.

If using SSL, there is little value in using CRAM-MD5 as opposed to having the client send the password over the SSL connection. There is a small advantage in that if the client inadvertently sends the password to a server impersonator, the password itself is not compromised immediately (only if cracked — though note that a server impersonator can send a constant challenge and therefore build a table (rainbow or other) of HMAC-MD5 values over plausible passwords). Where the password is a random string, this can be an advantage (the attacker can't use the value sent by client to impersonate it unless the server happens to send the same challenge as the attacker, which shouldn't happen). Where the password is a human one, there is no such advantage (as the password can be cracked anyway) and having to store the password in plaintext is a definite disadvantage.

Answer 2

There are three relevant weaknesses in this case:

• Improper password storage: If your provider's database is compromised, your password is directly exposed. Although some implementations of CRAM-MD5 don't store passwords in plaintext, the hashed password is still unsalted. So far, there's no known implementation that salts the password (the salt needs to be known to the client as well).

• Actual data travels in plaintext: By not using SSL, your emails are totally exposed to MiTM.

• Offline attack: Once the attacker acquires the information used for the authentication (the challenge sent by the server, the response sent by the client), he's able to brute-force the password offline.

• Chosen-plaintext attack: Because the attacker is able to impersonate the server, he's also able to send the challenge values he wants, and observe the client's response. This makes it easier to eventually know the password.

Mind you, none of these attacks are related to vulnerabilities in MD5 itself.

In conclusion: CRAM-MD5 is not secure for this purpose at all. Your provider has no excuse for storing passwords in plaintext, the issue here is just their reluctance to implement a better solution.

Answer 3

It gives no protection against MITM since an attacker could forward the challenge to the client. Requiring plaintext password storage is bad and the exchange can have have a dictionary attack run against it.

You are justified in being worried about this scheme and I'd personally suggest using a different e-mail provider.

Answer 4

Firstly, it's not necessary to use plaintext:

Looking at the HMAC-MD5 implementation in psuedocode:

you can at least store a modified version of the password:

    if (length(key) > blocksize) then
        key = hash(key) // keys longer than blocksize are shortened
    end if
    if (length(key) < blocksize) then
        key = key ∥ [0x00 * (blocksize - length(key))] // keys shorter than blocksize are zero-padded ('∥' is concatenation) 
    end if

    o_key_pad = [0x5c * blocksize] ⊕ key // Where blocksize is that of the underlying hash function
    i_key_pad = [0x36 * blocksize] ⊕ key // Where ⊕ is exclusive or (XOR)

Store the two XOR'd keys, there is added security in the fact that if your system is compromised, a user's accounts elsewhere that use the same password won't be compromised. Apparently Dovecot does this.

---

MD5 in itself is quite easy to brute force. An MITM attacker could brute force the password as s/he already knows the challenge.

Nowadays, the solution to almost all such problems is to just use SSL.

Answer 5

First off, the plaintext bit is bullshit - most POP/SMTP *nix solutions can be retrofitted to not need this. With this out of the way...

...CRAM-MD5 has shocking vulnerabilities - coming from its MD5 tie. However, it's still better than plaintext. In order of appearance and "OMGWTFBBQ-ness":

1. A server using CRAM-MD5 can be spoofed/MitM-ed as the client never checks for the server's authenticity
2. Passwords are crackable offline (which should be obvious)
3. All the MD5 vulnerabilities apply

CRAM-MD5 is effectively MD5( (key XOR padding) concat MD5(key XOR morepadding) concat value) coupled with challenge-responses. The key is the user's password - the value is the challenge. So, if the challenge is unknown, it'd be perfect. Sadly, it isn't, as it is transmitted in plain text.

Basically, avoid if you can. GPUs can compute a frightening number of MD5 hashes these days. However, a simple solution is just to SSL the lot. A certificate is worth peanuts these days.