CODEWITHSUNDEEP
cryptographysmtp
user187676
user187676

Reputation:

Is implementing CRAM-MD5 a good idea?

I'm writing an SMTP server and have implemented CRAM-MD5 auth. To calculate the challenge response string I apparently need to store a plaintext password on the server.

What's the reasoning behind this? This auth mechanism seems incredibly flawed, provided that:

To me CRAM-MD5 does seem LESS secure that a PLAIN/LOGIN auth, provided that TLS is always required.

Upvotes: 2

Views: 1362

Answers (3)

alexgirao
alexgirao

Reputation: 895

You are not required to store the clear text password on the server, you just have to store the MD5 contexts of the formula, it was designed specifically for this:

HMAC(K, M) -> H(K1, H(K2, M))

Note that K1 and K2 are always the first input of the hash and are always 64-byte long, no matter the size of the key/password, also note that this algorithm is compatible with other hashes (SHA1, SHA256, ...)

from RFC6151 (March 2011)

MD5 is no longer acceptable where collision resistance is required such as digital signatures. It is not urgent to stop using MD5 in other ways, such as HMAC-MD5

from RFC2195 (September 1997)

the use of the techniques described in [KEYED-MD5] for precomputation of intermediate results make it possible to avoid explicit cleartext storage of the shared secret on the server system by instead storing the intermediate results which are known as "contexts"

Upvotes: 2

Steven Sudit
Steven Sudit

Reputation: 19620

Yes, storing the password, even reversibly encrypted, is worse than a salted hash of some sort, due to password reuse. Arguably, generating something from the plaintext password (as by PBKDF2 or regular salted hash) and then using that on both sides would be somewhat more secure. However, it requires the client to know about the server's hashing scheme, including the salt used for this account. No matter how you slice it, that leaves you with something incompatible with CRAM-MD5 and not necessarily much better.

I'd suggest forgetting about CRAM-MD5 entirely because of this problem and others. In particular, it uses MD5, which is considered broken, and there are various known weaknesses. The biggest is that the connection is not encrypted, so anyone can sniff out the actual contents.

A better answer is to just use TLS.

Upvotes: 3

Maarten Bodewes
Maarten Bodewes

Reputation: 93998

Of course you could amend CRAM-MD5 to use the output of a PBKDF function such as PBKDF2 if you want to just keep a non-reversible password as key for CRAM-MD5. You would require the salt on both sides though.

This is however not very useful, as the attacker may use the output of the PBKDF2 directly to as input of the CRAM-MD5. So the only advantage then is that the user's password is not directly exposed (passwords are often reused). Using PBKDF2 on the server is highly recommended even with plain login, as it mitigates the effects of a compromised database.

Of course, using a version of CRAM-MD5 together with a KDF makes it a proprietary protocol, so interoperability will be impacted.

However, as retrieving the password means breaking TLS, PLAIN/LOGIN should be fine for most use cases.

Note that I'm not an expert regarding CRAM-MD5, I just quickly read the protocol on Wikipedia.

Upvotes: 0

Related Questions