Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 http://crypto.stackexchange.com/questions/8391/what-are-the-potential-security-impacts-of-using-cram-md5-for-emails-when-not-u

share|improve this question
1  
The crypto and infosec points of view are pretty much the same here as they're based on protocol analysis. There are complementary answers on Cryptography: crypto.stackexchange.com/questions/8391/… –  Gilles May 20 '13 at 19:56
    
Thanks for the heads-up, even when I disagree a little bit. See, I was looking for both points of view because a crypto-view focuses more on (let's just call it) the "magic behind the scenes" while the infosec-view takes a broader view on things. Meaning: a "security point of view" also looks at hazards and attack vectors beyond the cryptographic algorithm(s) used. At least, that's my take on this. On the other hand, you might be right too: a real crypto-professional will know it's ways in InfoSec and vice-versa. Yet, who am I to expect an ideal world where everyone is a pro in both areas? ;) –  e-sushi May 21 '13 at 13:19
    
fgrieu and I ended up covering mostly the same ground. I think this is a valid case for asking similar questions on two different sites with different audiences (even if the answers turn out to be similar in this case), but when you do this, do link the questions to each other, so that potential answerers and readers can see what the other side has already said on the topic. –  Gilles May 21 '13 at 18:37
    
Oh, now I understand what you meant... will do. –  e-sushi May 21 '13 at 22:38
add comment

5 Answers

up vote 7 down vote accepted

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.

share|improve this answer
    
Definitely wraps it up most usable for my understanding. Thanks! –  e-sushi May 17 '13 at 23:51
add comment

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.

share|improve this answer
    
Your answer almost go "accepted" by me, but the one that made it was a bit more usable to me in this case. I wish I could have at least accepted two answers, so I could've given your answer a thumbs-up for the short and on the point list of security issues involved. What can I say? I definitely love your answer and appreciate it to the fullest... it's just that the other one had "more flesh" which made the difference in the end. Nevertheless, thanks for your answer and involved efforts. I'll surely keep an eye on you around here. I would be happy to accept your answer instead next time. ;) –  e-sushi May 18 '13 at 0:07
    
@e-sushi Don't worry about it, my answer pays back when it's helpful to you. That's all we want here. –  Adnan May 18 '13 at 6:09
add comment

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.

share|improve this answer
    
AJ: most lambda *nix servers have this issue in order to be able to deal with more than one SASL mechanism. They're, however, all configurable to change this, however (I know this, I patched my own dovecot to check vs. SHA512 hashes). –  Sébastien Renauld May 17 '13 at 19:20
    
Yeah, I saw the Dovecot bit, but wasn't sure if their mail service provider was using that particular system. Either way, it's a huge risk to be taking with the credentials when you can get a trusted SSL cert for under $60 a year. –  AJ Henderson May 17 '13 at 19:22
    
AJ: pretty much. Pointed that out in my answer - also, you can get free non-extended SSL certs these days. There's really no excuse anymore, it's no longer 2004 when certs were going for $500/year. –  Sébastien Renauld May 17 '13 at 19:25
    
Thanks for your reply. Even when I didn't "accept" your answer, I sure appreciate it! –  e-sushi May 18 '13 at 0:02
    
@E-sushi no problem, thanks for the note. Nice thing about SE is we generally get lots of great answers. –  AJ Henderson May 18 '13 at 3:04
add comment

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.

share|improve this answer
    
Even when I "accepted" another answer, I would like to thank you for the additional information here. Between the answers presented here, it was hard to choose... but I can't accept them all. As said: thanks for your reply. I appreciate it! –  e-sushi May 17 '13 at 23:53
    
@e-sushi: You're welcome! No need to apologize for not accepting all, we don't mind :D –  Manishearth May 18 '13 at 6:11
add comment

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.

share|improve this answer
1  
What are the MD5 vulnerabilities that applies here? And how do they apply? –  Adnan May 17 '13 at 19:21
    
@Adnan: Assuming he's not using SSL (which he isn't), the password is used as the HMAC key. All the rest of the info used in computing the HMAC response are known from previous exchange. Can be brute-forced, and has been brute-forced. Cain even has a module for it. –  Sébastien Renauld May 17 '13 at 19:23
2  
I probably haven't phrased my question correctly. I'll try again, What are the MD5 vulnerabilities that applies here? And how do they apply? –  Adnan May 17 '13 at 19:25
1  
@Adnan: I have just mentioned: chosen-plaintext. publib.boulder.ibm.com/infocenter/zos/v1r12/… for more info. –  Sébastien Renauld May 17 '13 at 19:26
2  
Okay, I've finished reading that and nowhere it says anything about MD5 vulnerabilities. A chose-plaintext attack here has nothing to do with MD5. Even if you replace MD5 with SHA-512, the attack still applies. And here I go again, what are the MD5 vulnerabilities that apply here? –  Adnan May 17 '13 at 19:38
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.