1

I was reading about Windows Authentication in IIS7

I know from experience that Windows Authentication technically works OK over the Internet using IIS - meaning user is challenged with 401 not authorized, and that most browsers (Chrome, FF, IE, Safari) prompt for windows domain\user and password, and that if authentication succeeds, and if authorized, the user gets the requested page.

But then I read this:

Windows authentication is not appropriate for use in an Internet environment, because that environment does not require or encrypt user credentials.

HTTPS can be used for encryption, but I am seeking clarification on the other part.

What does "does not require user credentials" mean?

And based on that, the real question: besides using HTTPS for encryption, how do I implement Windows Authentication in a secure manner for use in an Internet environment?

The Microsoft claim seems unfounded. I get that if using NTLM instead of Kerberos you lose the direct connection to a trusted third party identity provider, but that doesn't explain to me why credentials would not be required if implemented properly. Seeking that method. Thanks.

nothingisnecessary
  • 71
  • 1
  • 9
  • You should really use a federated auth model like OAuth or SAML – Jim B Jan 24 '17 at 20:33
  • 2
    Thanks, and I don't disagree. But that was not the question – nothingisnecessary Jan 25 '17 at 06:32
  • I hear you - that's why it's a comment - not an answer. Personally I think the answer would be an opinion, and too broad, not an answer per se (which is why I voted to close) – Jim B Jan 25 '17 at 18:48
  • or maybe think of if this way: what are the weaknesses in a solution using windows auth + IIS + https + valid certifcates + ACLs over the Internet? or at least what are the weaknesses specific to that solution that are not also present in competing mainstream solutions? – nothingisnecessary Jan 31 '17 at 21:10
  • In the comments of that Technet article you linked, you will find the answer: "Learn about what is Kerberos, and you will see in Internet case, unless you expose your domain controllers publicly (which is a worst practice), Kerberos is by design to fail. As NTLM is always used for your Internet clients, and NTLM can be brute forced, Windows authentication is of course not recommended." – Michael Hampton Jan 31 '17 at 22:24
  • ... Which only partially makes sense to me. NTLM is of course a waste of time to even think about. But Kerberos was designed to operate over hostile networks, so I don't know what Microsoft's problem with it is. – Michael Hampton Jan 31 '17 at 22:26
  • it looks like NTLM tokens are passed via headers, is that why HTTPS alone doesn't suffice for securing NTLM auth? – nothingisnecessary Jan 31 '17 at 22:33
  • sigh... if only the IT my clients' companies hire were all smart like you guys. I think the problem is that all these big companies hired dudes who came of age in the 90s and they are still hanging on tooth and nail to their AD-based windows authentication and roll their eyes when ADFS and modern alternatives are mentioned. most of em don't use https either (even over internet) because they are too cheap to pay for certificates or send their staff to training. the best i can do is continue pointing to that article and say "look, Microsoft made this thing, but even they say not to use it!!" – nothingisnecessary Jan 31 '17 at 22:46

2 Answers2

1

The main reason for which you should not have local authentication for and internet facing site is the fact that if your webserver is being compromised all your local accounts are compromised. With Kerberos you can update passwords, and have a centralized control over authentification.

Now kerberos authentication can use SPN keytabs and you have different types of encryption https://uit.stanford.edu/service/kerberos/keytabs while NTLM only partially uses encryption https://blogs.msdn.microsoft.com/chiranth/2013/09/20/ntlm-want-to-know-how-it-works/. Unless NTLMSPP is fully supported and updated on your OS, you would be sending credentials in plain text http://www.cisco.com/c/en/us/support/docs/security/web-security-appliance/118487-technote-wsa-00.html and https://en.wikipedia.org/wiki/NTLMSSP. NTLM is currently not being extended and it's not the protocol of choice https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx.

As you can see, per MS documentation the username is in plain text and the password is hashed. Against NTLM "easy" attacks are possible - pass the hash, or predicting the random number generated in the session, then getting the password out of it. On top of that NTLM supports 56 and 128 encryption so it's lower than any fairly recent method.

There is no way to implement local authentication securely for a web facing service. Please let me know if that makes sense.

Alex H
  • 1,814
  • 11
  • 18
  • Thank you. In the end went with this answer because - even assuming HTTPS is used - it seems that weak encryption and lack of trusted third party identity provider (unlike in Kerberos, SAML, oAuth, etc.) for NTLM is the biggest risk factor. And thanks for supporting links; while I ultimately cannot control what my clients decide to do (despite strong recommendations for ADFS and the like) I have built these materials into a fact sheet to help justify moving away from winauth & ntlm. The problem is still under-trained IT staff at organizations that don't have tons of spending power, but oh well – nothingisnecessary Feb 08 '17 at 01:55
  • Glad that you found the answer useful. Usually you have issues regarding either budget, technical knowledge or you will be on the cutting edge with a big budget and you will need to adapt to really new technologies and concepts and make changes all the time. The point being you will always have to drive change and each environment has it's own benefits and disadvantages. – Alex H Feb 08 '17 at 10:54
1

most of em don't use https either (even over internet) because they are too cheap to pay for certificates.

Configuring the web site to require Https would provide a reasonable measure of security. If you're looking for something else because they don't want to use/pay for certificates, you're wasting everyone's time. Implementing Windows Auth over the Internet without requiring SSL would be irresponsible, because the integrated Windows auth mechanism may not work for a variety of reasons. When that occurs, they are challenged to enter credentials, that would be transmitted over the network in plain text if SSL were not required.

And we haven't even considered if the data needs to be encrypted.

Also, both NTLM and Kerberos send the http authorization header payload with every packet, and that header includes the hashed/munged credentials. Kerberos would be more secure than NTLM, but both could be susceptible to a MITM replay attack if SSL were not used.

In my experience, it can be difficult to get Windows Auth to work reliably even on internal networks, and prompting for credentials over unencrypted http connections when it doesn't work is a weakness that cannot be ignored. There are a variety of scenarios where it may not work, including the token/auth header is too large due to group memberships and/or insufficient IIS configuration settings, or Windows credentials are out of sync between the client and the Active Directory domain. The token size too large problem only occurs with Kerberos, because the group memberships are stored in the Kerberos PAC.

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • Thanks and +1! Very good details. It was tough choice but I awarded bounty to other answer because it called out specifics of NTLM encryption and rolled with the assumption I already made which is that HTTPS is at least recommended (I get paid whether customer chooses to follow my recommendation or not) – nothingisnecessary Feb 08 '17 at 01:50