Is NTLM (over HTTPS) on IIS a good idea for a Internet-facing website

Question

I am writing here since I have a huge doubt. I am performing a technical security assessment on a custom developed web application (ASP.NET).

The application:

• is Internet-facing
• Uses HTTPS
• Uses IIS with NTLM authentication with NTLMSSP message protocol
• Lack of HSTS
• ASP.NET framework is not updated (v.4.0.xxx) - this will be a separate observation

My assessment is risk-based and I have read several publicly available resources related to NTLM over HTTPS, however, I cannot come up with a clear idea if I should suggest changing the authentication or not.

I learned:

• NTLM over HTTPS is better than basic or digest, since NTLM does not transmit credentials over the network, but transmits encrypted challenge/responses messages:
• Microsoft is kind of trying to move clients towards Kerberos. Is this true and does this apply for Internet-facing web apps?
• NTLM was affected by multiple vulnerabilities in the past, even recently: CVE-2019-1040, CVE-2019-1019. Per my understanding, SMB relay attack scenario should be applicable, however, It the likelihood seems low (attackers should be in a privileged position in the network and have another server to relay the attack). However, the protocol comes with concerns: https://www.preempt.com/blog/the-security-risks-of-ntlm-proceed-with-caution/
• NTLM does not support MFA
• NTLM protocol is old

My conundrum is:

• "should I point out this auth protocol as non-secure?" (meaning, should i say to the system owner to change the auth protocol?)
• If I do, "what are the alternatives or risk remediations?"

Answer 1

Secure HTTPS

Using HTTPS is great though a secure protocol and cipher must be used. There are a number of vulnerability scanners that will test this. Here are two examples:

1. Qualys SSL Server Test
2. Nmap ssl-enum-ciphers

NTLMv2 is Fine

You didn't specify whether NTLMv1 or NTLMv2 was being used. If the former (NTLMv1), this would definitely be a finding and cause for concern. There's no reason for that protocol to be in use nowadays especially on a public facing application. NTLMv2 is perfectly fine and some may consider it more secure than alternatives since it works on a challenge/response where the actual password isn't even sent to the server. As an example, Microsoft SharePoint and Exchange can have publicly facing components using NTLM authentication.

Difficulty with Windows Authentication

No Kerberos

NTLM authentication is the default authentication method when the application is configured to use Windows Authentication. This is because Kerberos requires extra configuration steps and the client needs access to the Kerberos infrastructure (i.e. Domain Controller). This would be fine if the web application is only accessed from the LAN or via a VPN. However a public facing web application doesn't make this a feasible option.

Lacking Session Management

Windows Authentication lacks control over session management. Take for example an app using Forms Authentication, the session cookie can be expired after a specified time or extended on each request. This isn't the case with an application using Windows Authentication. Failure to properly terminate a session would definitely be a finding.

No Branded Login Page

The Windows Authentication login box is the generic window provided by the browser. Many prefer to provide the user a "Branded" login page as it allows the user to be more aware of what application they're about to log into. Checking the URL bar to ensure the location is accurate and certificate is valid (e.g. colored green). This leverages end-user education on phishing prevention and good security awareness. Depending on your environment, this could be a finding.

No Brute Force Protection

Generally there are two methods to protect a website against brute force login attempts: MFA and captcha. Be default, a web application using Windows Authentication doesn't support MFA. You may find an provider that leverages a module to achieve this but I'm guessing you're not using one of those providers. Regarding captcha, there is no way to implement that. This requires one to monitor the web application for brute force login attempts.

To address this, I wrote a PowerShell module WebsiteFailedLogins. From the README:

This PowerShell module was created to identify the following scenarios affecting IIS hosted websites.

• Brute Force Login Attempts - excessive failed logins from a single IP address and often targeting a single account.
• Password Spraying Attempts - excessive failed logins from a single IP address using a single password across multiple user accounts.
• Distributed Login Attempts - either of the above techniques being sourced from multiple IP addresses.

It leverages Microsoft Logparser and a configuration file to parse the target website's IIS logs. When a threshold is met or exceeded an alert is generated via standard out, email, and/or written to a Windows Event Log. No changes are needed on the webserver. This module can even run on a separate system where there's access to the IIS logs.

Older Framework

This isn't necessarily a finding. Run Windows Update, or whatever product you use to manage Security Updates, on the server running IIS. If there are missing updates then it will obviously be a finding. Check CVE's for any addressing the web application CLR. Chances are, if there are no missing security updates there will not be an open CVE.

Check Supporting Components

If you're concerned about an older framework, this leads me to believe the application itself is dated. Look into supporting components like jquery to ensure they're not using an insecure version. This may reveal a finding.

Alternative - Forms Authentication

With HTTPS configured to use a secure protocol and cipher, the best alternative is Forms Authentication. While the login credentials are transmitted in clear text; secure HTTPS mitigates this. It also achieves:

1. Better Session Management
2. A Branded Logon Page
3. MFA or Captcha Integration

This approach will require a retooling of the web application. Two caveats to be aware of include:

1. The web application must use a secure method of authenticating credentials on the backend. Whether its Kerberos or LDAPS, just be sure the credentials are not shared in an insecure manner on the backend.
2. Access must be tested to ensure resources are not accessible via insecure methods. For example, by default MVC applications would use a static handler to improve performance when serving .js and .css files thus bypassing the authentication requirement. In some instances these resources should be accessible to authenticated users only.

Alternative - SSO

The best method to address these authentication issues is to implement a Single Sign-On (SSO) provider. It will still require the web application to be retooled for the new authentication method. However, long term this is the best approach as it centralizes authentication for the enterprise.