Say you have to choose only one among the following authentication types for your own SMTP server:

  • CRAM-MD5

Which one would you recommend for optimal security?

PS: The list is the authentification types given in man swaks

  • 2
    None of these authentication types are really secure without TLS! – trognanders Dec 27 '16 at 19:50
  • They are all equally secure unless your TLS implementation is buggered. – Navin Dec 28 '16 at 14:47

With SSL/TLS it's okay to use LOGIN / PLAIN.

You should provide SMTP on top of an SSL-encrypted connection. While some schemes from your list (e.g. DIGEST-MD5) can keep a password secure even over an untrusted channel, they won't protect users from a man-in-the-middle attacker tampering with their session. (Commonly, email servers wrap SMTP via direct TLS or a connection upgrade with STARTTLS at the ports 465/587.)

Any SMTP auth type, regardless if you usePLAIN or an advanced method, just provides application level authentication. But what you want is transport level security. After a user is authenticated over SMTP, there will be no automatically encrypted connection. Per the SMTP protocol, commands and emails are exchanged with the server in plain text, allowing a man-in-the-middle attacker to read and modify the communication and inject new commands. That's why you should provide it on top of SSL encryption, just like HTTPS provides HTTP on top of SSL.

The HTTP analogy: If you secure your website with HTTPS, then it doesn't matter that the a login form actually transmits your password as a plain string in the POST body of the HTTP request, because the data transport is SSL-encrypted. Enabling CRAM-MD5 for SMTP is analogous to implementing a challenge-response scheme in Javascript before transmitting login credentials to a website. (You can occasionally see that technique in router interfaces which don't provide HTTPS but it's not very common.)

As for a real-life example, GMail is fine with offering LOGIN / PLAIN authentication (where credentials are sent in plan text) after having established a secure SSL connection:

$ openssl s_client -starttls smtp -connect smtp.gmail.com:587 
EHLO foo
250-smtp.gmail.com at your service, []
250-SIZE 35882577

(As you can see, they also provide some methods you didn't list, e.g. XOAUTH2 for OAuth2 tokens which might be interesting if you're after passwordless authentication.)

  • Even with TLS, you should still use a scheme that doesn't disclose the password. In case of either server compromise or TLS certificate forgery, if you're using PLAIN, the attacker got the password and can establish any number of sessions to the real server (and to other systems using the same password) at any time. If instead one of the nonce-based schemes such as DIGEST-MD5 was used, the attacker gets only a single live session and cannot establish any additional sessions. So no, they are not all equal, even in the presence of TLS. – Ben Voigt Dec 28 '16 at 16:47
  • @BenVoigt An MITM attacker who forged the TLS certificate could switch the authentication method back to PLAIN to trick the client into providing the clear password. That would only be prevented if the client enforces a particular auth type. – Arminius Dec 28 '16 at 17:09
  • @Arminius: Agreed, the client needs to be configured with a minimum security level. – Ben Voigt Dec 28 '16 at 18:22
  • @Arminius: One can also consider Heartbleed-like attacks, which would leak some of the decrypted data, but not allow the attacker to control the authentication method, nor perform stream modification as would be possible for a MITM without TLS. In such cases, leaking the plaintext password is far worse than leaking a salted&peppered hash. – Ben Voigt Dec 28 '16 at 18:30
  • @BenVoigt I get your point. But doesn't the same reasoning apply to HTTP login forms? We accept that such credentials are transmitted in plain text on the application layer although a password could also be hashed on the client side. – Arminius Dec 28 '16 at 18:50

What I call a nice authentication is one that has the following properties:

  • the server never has to know the actual password but only keeps a hash of it

    This ensures that even if the password database is ever compromised, the attacker will only get hard to invert hashes, and users would have enough time to change their passwords

  • the password is never exchanged in clear text

    What is exchanged can be spied too easily, and a password that pass in clear text over a non encrypted channel should be seen as compromised

Provided the SMTP server allow TLS, PLAIN respect both with the following scenario: HELO, STARTTLS, LOGIN

  • Is there any authentication scheme that doesn't have the first property? – Rhymoid Dec 28 '16 at 10:40
  • @Rhymoid: AFAIK, in the NTLM mode the password is known to the server – Serge Ballesta Dec 28 '16 at 11:42
  • Does the server need to know more than the LM Hash and/or the NT Hash of the password? The fact these hashes are broken is a separate problem. – Rhymoid Dec 28 '16 at 12:28

Apart from best recommendations for SMTP, here is your available list:

  • LOGIN, PLAIN: Password is transferred in clear-text.
  • CRAM-MD5: Weak against chosen plaintext and has password storage issues.
  • DIGEST-MD5: Better than CRAM-MD5 as it is stronger against chosen plaintext attack and permits the use of third party authentication servers
  • NTLM/SPA/MSN: NTLM authentication which is also vulnerable to chosen plaintext.
  • 2
    All of these are insecure if you're not using SSL/TLS. – Flimm Dec 28 '16 at 13:52
  • Agree, and my answer is for the question and not the best recommendations for SMTP. – Opaida Dec 28 '16 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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