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:
- Qualys SSL Server Test
- 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
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.
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:
- Better Session Management
- A Branded Logon Page
- MFA or Captcha Integration
This approach will require a retooling of the web application. Two caveats to be aware of include:
- 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.
- 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.