Windows NT Challenge/Response authentication (often called NTLM authentication) is the most secure form of authentication because the user name and password are not sent across the network. Instead, the Windows Security Provider interface is used to provide an encrypted challenge/response handshake mechanism that is functionally unbreakable. The Windows security provider interface allows IIS to validate and impersonate the user. Unlike Basic authentication, NTLM authentication does not initially prompt users for their user name and password. The current Windows user account on the client computer is used for the NTLM authentication. Then, if this fails, it will prompt the user for the user name and password. If NTLM authentication succeeds, the requested application or resource is executed in the context of the specified user.
Because one-way encryption is used, NTLM authentication validates the user for IIS without providing knowledge of the user's password to IIS. Therefore, a full set of user name and password credentials is not available to IIS for doing such tasks as mapping a network drive. For instance, if an ISAPI application calls the WNetAddConnection2 function without specifying a user name and password, it will fail under NTLM authentication.
Although Windows NT Challenge/Response is very secure, it does have a couple of limitations. First, only Microsoft browsers support this proprietary scheme. Second, Windows NT Challenge/Response does not work over HTTP Proxy connections. Because of these limitations, Windows NT Challenge/Response may not always be the best choice for an Internet server, although it is often ideal for intranet use. As you can see, choosing an authentication method is a trade-off in security verses flexibility.