5

I have a Windows SMTP server that is currently allowing the "AUTH LOGIN" method of authenticating. As I now know, this is simply a base-64 encoding of the username and password, which is basically as bad as plaintext, as spammers can sniff out the plaintext password in transit.

As a quick fix, Integrated Windows Authentication (IWA) is available for me to use. I believe that IWA uses "AUTH NTLM" authentication. Is this considered "secure enough"? Are there any vulnerabilities in the wild that make "AUTH NTLM" a bad idea?

anon
  • 152
  • 1
  • 8

1 Answers1

4

The bad idea is not the use of NTLM, but the lack of use of SSL. Without SSL, data travels unprotected, and, in particular, active attackers may hijack the connection (for instance right after the authentication was performed). No amount of NTLM will fix that.

To use SSL with STMP, there are two ways:

  • Run the whole SMTP transaction in a SSL server. The client must be aware, beforehand, that it is expected to begin the transaction by a SSL handshake. The traditional port for a STMP-within-SSL server is 465.

  • Have the client and server use STARTTLS. Connection begins with the "normal" port (25), but the client and server then negotiate the use of SSL/TLS and, after that negotiation, begin a SSL/TLS handshake.

Either way, you must configure the client not to send the password "as cleartext". Most clients can be configured that way.

If you use SSL/TLS then sending the user name + password "as is" is fine. If you do not use SSL/TLS, then switching from basic authentication to NTLM may slow down the less competent attackers, but don't believe that it will really thwart them. The cryptography in NTLM is not exactly worth a lot of enthusiasm, but the biggest problem with raw NTLM over an unprotected socket is the same as raw login+password over an unprotected socket: the socket is unprotected.

Compared to basic authentication, NTLM does not show the password itself, so passive only attackers will not learn the password immediately; however, they obtain a password hash, with a very fast hash function (a few MD4 and MD5, at most), meaning that brute force on the passwords will be effective. A passive-only attacker with a good GPU still has a good chance of breaking some user passwords.

A good reason to switch to NTLM is integration with other authentication methods, e.g. smart cards. But if your users have passwords, then basic authentication does the trick with less hassle.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • My experience is that most SMTP based TLS connections don't verify the cert, or allow for numerous exceptions that aren't normally allowed in the HTTPS scenarios. Is this your experience as well? Things I've seen include: expired certs, non matching subject, cert chain issues, etc. – makerofthings7 Apr 02 '13 at 17:28
  • Thanks for the informative answer. Is there malware "out in the wild" that either does the bruteforce or hijacks the connection? That is, if my recommendation to use SSL/TLS gets vetoed and I *only* used NTLM, are there existing "drive-by" attacks that can already be used by script-kiddies to compromise the passwords? – anon Apr 02 '13 at 17:33
  • The [WiFi pineapple](http://hakshop.myshopify.com/products/wifi-pineapple) is an off-the-shelf device which is very convenient to hijack connections, when the target user connects over some "free WiFi" (as is often the case for people who travel with their laptops). – Thomas Pornin Apr 02 '13 at 17:41