Fried Fish

Support for Windows Integrated Authentication

I'm frequently asked to explain why Mozilla does not fully support Windows Integrated Authentication. A lot of sites running Squid or Microsoft IIS proxies utilize NTLM authentication, and users of IE will silently logon to the proxy servers without being prompted to enter their domain, username, and password. This is a nice feature for intranets. In Mozilla, the user is prompted once per browser session, which is a problem because:

1. Users do not expect to be prompted and may not understand what they are supposed to enter.
2. If users ask mozilla to remember their username and password, that will help provided the site does not expire passwords frequently.
3. It causes extra support headaches for intranet admins.

I posted a comment about our implementation and plans for the future here:

http://forums.mozillazine.org/viewtopic.php?p=631269

My comment is copied here:

---

> Is there a technical difficulty or policy reason as to why transparent NTLM auth hasn't been implemented on Win32?

Yes, the challenge is that it requires 1) that we use Microsoft's NTLM implementation (via SSPI), and 2) that we limit when we use it.

Challenges related to #1:

• Older Windows systems only support NTLMv1, which uses a weak password hashing algorithm that is easily cracked.
• A stronger form of NTLM can be negotiated but the client needs to have a newer SSPI implementation.
• Older versions of SSPI are buggy and sometimes crash Mozilla. We do not know why this happens.

Challenges related to #2:

• We do not want to silently send a NTLMv1 hash of your password to any server that requests it. We must limit automatic authentication to a "whitelist" of allowed sites. (This is obviously not an issue for proxy servers.) IE solves this problem via Security Zones, but there is no such concept in Mozilla.

Our plans:

• For Win32, support Negotiate (SPNEGO) and NTLM via SSPI when a site matches our whitelist of allowed sites.
• Require user prompting when visiting a site outside the whitelist.
• Disable SPNEGO when visiting a site outside the whitelist.
• Add UI to allow the user (or admin) to add sites to the whitelist.

Additionally:

• We may want to use our internal NTLM implementation instead of the SSPI NTLM when handling a user identity that was retrieved from a prompt. In such cases, we may want to ensure that the highest grade NTLM is used since it may be sent over the world-wild-web.

See bug 249942 for whitelist UI.
See bug 237586 for code that uses SSPI for SPNEGO (and not yet raw NTLM).

Posted by darin at July 8, 2004 8:16 AM