18

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

  • LOGIN, PLAIN
  • CRAM-MD5
  • DIGEST-MD5
  • NTLM/SPA/MSN

Which one would you recommend for optimal security?

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

AnFi
  • 223
  • 1
  • 4
user123456
  • 520
  • 1
  • 4
  • 13

3 Answers3

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 
 ...
250 SMTPUTF8
EHLO foo
250-smtp.gmail.com at your service, [127.0.0.1]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
...

(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.)

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • 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
  • @Arminius: I take it you mean "HTML forms". Actually, those suck at security. HTTP authentication (using MIME headers), where the password is typed into a browser-provided window not the web page, supports better authentication schemes just like SMTP. Not only can the browser perform hashing preventing the server from getting the plain text password, but the password is also kept out of reach of Javascript, so all kinds of cross-site scripting and injection attacks are mitigated. But that really deserves a question all its own. – Ben Voigt Dec 28 '16 at 19:19
4

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.
Opaida
  • 323
  • 1
  • 3
3

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

Community
  • 1
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84