Closed Bug 828183 Opened 11 years ago Closed 10 years ago

Disable insecure NTLMv1 authentication

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30
Tracking Status
relnote-firefox --- 30+

People

(Reporter: briansmith, Assigned: mayhemer)

References

Details

(Keywords: dev-doc-complete, sec-high, site-compat, Whiteboard: problems? try network.negotiate-auth.allow-insecure-ntlm-v1 = true)

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #423758 +++

> NTLM Compatibility Levels
> http://msdn2.microsoft.com/en-us/library/cc207934.aspx
> http://davenport.sourceforge.net/ntlm.html#ntlmVersion2

Recently it has been discovered that NTLM before NTLMv2 is basically completely insecure. So, we should disable all pre-v2 NTLM support.

Note that we don't support NTLMv2 on all platforms yet: see bug 423758. That said, I am not sure that we need to block this on fixing bug 423758.
If the feature is presented as secure but it isn't we should remove it. Honza - what do you think? Can you do this?
Assignee: nobody → honzab.moz
For windows clients:

There is no way to programmaticaly instruct the SSPI API to allow only NTLMv2 responses.  According http://technet.microsoft.com/en-us/library/cc736506%28v=ws.10%29.aspx clients can setup their group policy for the computer to require NTLMv2.  It is inherited from AD servers too.  The corresponding registry key is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0\NtlmMinClientSec
Flag: 0x00080000 - NTLMv2 session security required


According http://support.microsoft.com/kb/147706 I've also setup an IIS server to send only NTLMv2 response using:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\LMCompatibilityLevel = 3

In this environment I was able to connect such server with Firefox (Aurora, Nightly, I believe any version after Fx 3.6.1 works).   Confirmed with Wireshark there were only NTLMv2 communication.

With standard prefs Firefox is using internal SSPI on Windows, so if clients are configured properly, we are safe.


For other platforms:

On Linux we use ntlm_auth binary helper from samba.  I need to find out how to setup this helper to reject LM and NT responses, or if we can parse the response and stop on missing NTLMv2.
Hmm... documentation differes:
[1]
3: Domain controllers accept LM, NTLM, and NTLMv2 authentication.

[2]
Level 3 - Send NTLMv2 authentication only

[3]
Server sends NTLM v2 response only. 
DCs accept LM, NTLM, and NTLM v2 authentication.

Hard to say what is what..  Retried with 5, that is documented correctly in all.  Same result.  

However, I'm really not sure I forced the expected server behavior.  Thus, I don't have a testing environment for Linux to check on...

Brian, do you still have your NTLM/win server images?  They were based on more modern server then WS2003 which I have, IIRC.

[1] http://technet.microsoft.com/cs-cz/library/cc960646.aspx
[2] http://support.microsoft.com/kb/147706
[3] http://social.msdn.microsoft.com/Forums/en-US/os_interopscenarios/thread/c8f488ed-1b96-4e06-bd65-390aa41138d1/
OK, figured that out!

- win7 pro box with IIS running
- no AD, the box is not part of a domain, just a standalone machine
- open Group Policy editor
- Local Computer Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Network security: LAN Manager authentication level
- set it to "Send NTLMv2 response only. Refule LM & NTLM"

With this setting my linux box with samba and working ntlm_auth cannot connect.

Switching to "Refuse LM" only allows to connect, that proves ntml_auth generates NTLM (v1) response.

I can work with this.
Can we get a patch for this, Honza?
(In reply to Al Billings [:abillings] from comment #5)
> Can we get a patch for this, Honza?

There is probably nothing to patch.  On all systems disabling v1 is depending on system and server setting only, we don't have handles to influence it.

Our generic module, that is used when system support is not avail, only supports v1.

So, my guess here is that we should disable our generic module until it supports (only) v2.

I don't right now have time to do it, but if this is raised a prioroty (over http cache rewrite namely) I can spend cycles here.

Jason?
Flags: needinfo?(jduell.mcbugs)
(In reply to Honza Bambas (:mayhemer) from comment #6)
> (In reply to Al Billings [:abillings] from comment #5)
> > Can we get a patch for this, Honza?
> 
> There is probably nothing to patch.  On all systems disabling v1 is
> depending on system and server setting only, we don't have handles to
> influence it.
> 
> Our generic module, that is used when system support is not avail, only
> supports v1.
> 
> So, my guess here is that we should disable our generic module until it
> supports (only) v2.
> 
> I don't right now have time to do it, but if this is raised a prioroty (over
> http cache rewrite namely) I can spend cycles here.
> 
> Jason?

The generic NTLMv1 implementation should really be disabled by default, in my opinion. It often causes harm being enabled by default under OS X:

For example, servers that operate over TLS offering NTLMv2 and then Basic authentication are inaccessible to Firefox on a Mac unless the user knows to press Escape to the first authentication challenge. NTLMv1 is otherwise attempted and fails.

(In IIS6, integrated authentication always takes precedence over Basic so an administrator cannot change the order so are in a rock and a hard place and often have to say to users: Use Safari instead.)

Better than that, is it possible we might see a generic NTLMv2 implementation at some point? Pretty please? :P

Nick
Honza, did bug 887984 give us the telemetry to make a decision here?
Flags: needinfo?(jduell.mcbugs) → needinfo?(honzab.moz)
Not sure, but even though the probe is partially screwed up, it visibly shows that NTLM is not used on linux and osx almost at all (~80 hits after 3 weeks on the release channel!).  

Darwin:  50:50 for generic/gssapi
Linux:   75:25 for generic/gssapi
Windows: 99.99:0.01 for sspi/generic  (12k+/200 hits)

No idea what is direct/proxy ratio.


Hard to say what to do here.  We can experimentally turn the generic module completely off.  It won't affect majority of windows users, definitely.  And on osx/linux definitely as well, it can probably just help :)
Flags: needinfo?(honzab.moz)
This has been drifting along for 10 months.  Can we get some movement on here?  Or maybe this isn't really sec-high?
Honza, yes, sounds like the right solution is to disable the generic module.
Honza, got a patch brewing?
Flags: needinfo?(honzab.moz)
No tat the moment, I'll try to get to this in some spare time.
Status: NEW → ASSIGNED
Flags: needinfo?(honzab.moz)
Brian, do you agree to disable the NTLM generic module?  That is the only module we have a control of and that enables (actually only knows) NTLMv1.
Flags: needinfo?(brian)
Sure, sounds fine to me.
Flags: needinfo?(brian)
https://twitter.com/bagder/status/425585112131330048:
NTLMv2 patch for #libcurl up for review: http://curl.haxx.se/mail/lib-2014-01/0183.html

Maybe Daniel is interested in this.
Yeps I am!

I've written most of the libcurl NTLM code and I'll help merge this new NTLMv2 code into libcurl so I think I may have a good position to work on NTLMv2 for Firefox too, even though I've not been involved in firefox ntlm before and I've not yet investigated the test suite setup/environment for it etc.
I'm confused now - Daniel, you want to work on this bug?  I right now have a bit of time to just remove or disable the generic module.  What is the plan then?

If you want to work on this bug, just ask and take it (change the Assignee field).
I know of bit of NTLM and I'm interested in helping out to get the situation improved, but as you've already done some work on this and gotten familiar I think you're closer to get something done about it. I'm still a newbie around this code and Firefox in general!

So please go ahead. I'll be watching and I'll chime in and help if I can and if its needed.
Enable to test, I refuse windows server setting fight...
Attachment #8364646 - Flags: review?(brian)
Comment on attachment 8364646 [details] [diff] [review]
v1 (actually a one line change)

Review of attachment 8364646 [details] [diff] [review]:
-----------------------------------------------------------------

OK. I guess we don't have any way of testing this.
Attachment #8364646 - Flags: review?(brian) → review+
https://hg.mozilla.org/mozilla-central/rev/d8681c43683d
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
I believe this broke my Exchange calendar support on Linux (via Lightning and Exchange 2007/2010 Calendar and Tasks Provider).

Could this be made a runtime preference (hidden, off by default), rather than a compile time flag? Or is there a timeline on NTLMv2 support for non-windows?
I am not convinced that is a great idea as NTLMv1 is highly security vulnerable when not under the protection of SSL/TLS.
If the Exchange server were configured correctly, it would reject NTLMv1 attempts too.

http://support.microsoft.com/kb/2793313
That may be so, but I am still left unable to use my corporate calendar with the recent nightly.

What about cross platform NTLMv2 support? Is that even on the radar, or are OS X/Linux going to be left completely broken? Keep in mind that this is not just Firefox, but Thunderbird as well (where NTML support seems more meaningful).
There is support definitely for linux: samba's ntlm_auth binary we support, then GSSAPI (which I'm not familiar with, but AFAIK this is Kerberos stuff) which we support too.
In lite of not further spamming this, what mailing list would be most appropriate for this discussion?
(In reply to Honza Bambas (:mayhemer) from comment #27)
> There is support definitely for linux: samba's ntlm_auth binary we support,
> then GSSAPI (which I'm not familiar with, but AFAIK this is Kerberos stuff)
> which we support too.

Firefox on Linux can no longer access any web content on a corporate network with Microsoft ISA proxy server. Changing any of the auth flags in about:config does not help. See also Bug 968254.

May I humbly suggest not to irrevocably disable NTLMv1 for proxy access on Linux as long as NTLMv2 (Bug 423758) is not ready?
Again, if that corporate ISA server was configured correctly, it would reject NTLMv1 as it is highly security vulnerable.

For example, you cut put a NTLMv1 hash through https://www.cloudcracker.com/ to reverse it.
(In reply to Nick Lowe from comment #30)
> Again, if that corporate ISA server was configured correctly, it would
> reject NTLMv1 as it is highly security vulnerable.

I understand your rationale completely. I am with you here. The proxy does support Negotiate, Kerberos, and NTLM. Firefox does not. Reading Honza's comment above, I think I understood that it is supposed to work. It does not.

If you disable the only working proxy authentication method, you are not making the network any more secure, you are only eliminating Firefox from the equation.

We do support Windows 7, Windows XP, Linux, and Android. We prefer to have the same browser on all platforms. As of now, this is Firefox. Help us keep it that way. Please.
First make sure you drop "network.auth.force-generic-ntlm" to false.

If you are connecting an NTLM proxy, try setting "network.automatic-ntlm-auth.allow-proxies" to true.

If you are connecting a server, add its full url ("http://example.com") to "network.automatic-ntlm-auth.trusted-uris", see [1] on how to format the pref when you want more urls trusted.

If the server host name is not a fully qualified name, set "network.automatic-ntlm-auth.allow-non-fqdn" to true.


Then there is a similar set of prefs for Negotiate auth at [2].


[1] http://hg.mozilla.org/mozilla-central/annotate/d05c721ea1b0/extensions/auth/nsHttpNegotiateAuth.cpp#l322
[2] http://mxr.mozilla.org/mozilla-central/source/extensions/auth/nsHttpNegotiateAuth.cpp#44
Thanks for the handy summary, Honza! All auth flags are set as requested. Proxy auth still fails as of 2014-02-05:

GOOD: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-04-03-02-01-mozilla-central/firefox-30.0a1.en-US.linux-i686.tar.bz2

FAIL: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-05-03-02-03-mozilla-central/firefox-30.0a1.en-US.linux-i686.tar.bz2

The authentication method chosen (among Negotiate, Kerberos, NTLM) in case of success is indeed NTLM. (Checked with LiveHTTPHeaders.)
Depends on: 999306
In Cuba the Firefox users have problems for surf on Internet with Firefox 30+. In Linux is impossible surf through proxy server, never show the dialog for authentication.
In Windows, Firefox ask password every time and is very hard surf. Like this https://bugzilla.mozilla.org/show_bug.cgi?id=318253
Before, we set true the preference network.auth.force-generic-ntlm but now not show the dialog for authentication and connection to proxy fail.

http://firefoxmania.uci.cu/firefox-me-pide-contrasena-muchas-veces-que-hago/
(In reply to Yunier J. from comment #34)
> In Cuba the Firefox users have problems for surf on Internet with Firefox
> 30+. In Linux is impossible surf through proxy server, never show the dialog
> for authentication.
> In Windows, Firefox ask password every time and is very hard surf. Like this
> https://bugzilla.mozilla.org/show_bug.cgi?id=318253
> Before, we set true the preference network.auth.force-generic-ntlm but now
> not show the dialog for authentication and connection to proxy fail.
> 
> http://firefoxmania.uci.cu/firefox-me-pide-contrasena-muchas-veces-que-hago/

Please look at comment 32 in this bug and if nothing of it helps, I think you need bug 999306 (just landed in version 30 and 31).  There is now a pref you can switch: network.negotiate-auth.allow-insecure-ntlm-v1
(In reply to Honza Bambas (:mayhemer) from comment #35)
> (In reply to Yunier J. from comment #34)
> > In Cuba the Firefox users have problems for surf on Internet with Firefox
> > 30+. In Linux is impossible surf through proxy server, never show the dialog
> > for authentication.
> > In Windows, Firefox ask password every time and is very hard surf. Like this
> > https://bugzilla.mozilla.org/show_bug.cgi?id=318253
> > Before, we set true the preference network.auth.force-generic-ntlm but now
> > not show the dialog for authentication and connection to proxy fail.
> > 
> > http://firefoxmania.uci.cu/firefox-me-pide-contrasena-muchas-veces-que-hago/
> 
> Please look at comment 32 in this bug and if nothing of it helps, I think
> you need bug 999306 (just landed in version 30 and 31).  There is now a pref
> you can switch: network.negotiate-auth.allow-insecure-ntlm-v1

Thank you @mayhemer, the comment 32 not help me, but switch the new preference (1) landed in last Nightly work perfectly in Windows and now can surf without cntlm proxy.
Soon I will test on Linux and probably work! 

1- network.negotiate-auth.allow-insecure-ntlm-v1
I think that it must be announced on all channels because represent some very significant for end user. We going to publish it on our web site firefoxmania.uci.cu and try inform to major people possible.
I wrote a small blog post that tries to describe all the NTLM preferences and the current status at http://www.janbambas.cz/ntlm-v1-and-firefox/.
Whiteboard: problems? try network.negotiate-auth.allow-insecure-ntlm-v1 = true
Work on Linux.
Can Mozilla set true by default [1] preference? If is possible, look it https://bugzilla.mozilla.org/show_bug.cgi?id=890638 related with [2]

[1] network.negotiate-auth.allow-insecure-ntlm-v1
[2] network.auth.force-generic-ntlm
(In reply to Yunier J. from comment #39)
> Work on Linux.
> Can Mozilla set true by default [1] preference? 

No.  The whole purpose is to protect users from incidental use of NTLMv1.  So, this will remain by default at false.

> If is possible, look it
> https://bugzilla.mozilla.org/show_bug.cgi?id=890638 related with [2]
> 
> [1] network.negotiate-auth.allow-insecure-ntlm-v1
> [2] network.auth.force-generic-ntlm

I closed that bug.
(In reply to Honza Bambas (:mayhemer) from comment #40)
> (In reply to Yunier J. from comment #39)
> > Work on Linux.
> > Can Mozilla set true by default [1] preference? 
> 
> No.  The whole purpose is to protect users from incidental use of NTLMv1. 
> So, this will remain by default at false.
> 
> > If is possible, look it
> > https://bugzilla.mozilla.org/show_bug.cgi?id=890638 related with [2]
> > 
> > [1] network.negotiate-auth.allow-insecure-ntlm-v1
> > [2] network.auth.force-generic-ntlm
> 
> I closed that bug.

No problem, I expect that it will be fixed. 
I want know if possible set true to default [1]. Brian can you tell me, please?

[1] network.negotiate-auth.allow-insecure-ntlm-v1
We'll never set  network.negotiate-auth.allow-insecure-ntlm-v1 to true by default.  It causes passwords to be sent in clear text.  Users/sysadmins who want it anyway just have to set the pref.
(In reply to Jason Duell (:jduell) from comment #42)
> We'll never set  network.negotiate-auth.allow-insecure-ntlm-v1 to true by
> default.  It causes passwords to be sent in clear text.  Users/sysadmins who
> want it anyway just have to set the pref.

Well, then Firefox always has sent passwords in clear text because all most of people here use NTLMv1.
Where I study, we use a proxy server for surf on Internet and with network.negotiate-auth.allow-insecure-ntlm-v1 false, we can´t surf and show an error like this:
ERROR
Cache Acceso Denegado
Se encontró el siguiente error al intentar recuperar la dirección URL: http://google.com.cu/
    Acceso Denegado a la Caché
Lo lamento, tu no estás autorizado a solicitar http://google.com.cu/ de este caché hasta que te hayas autenticado.
Depends on: 1023925
Some OS X and Linux users are reporting sign-in difficulties on their corporate intranet sites due to this change. The release notes should mention it.
relnote-firefox: --- → ?
Flags: needinfo?(lsblakk)
(In reply to Kohei Yoshino [:kohei] from comment #46)
> Some OS X and Linux users are reporting sign-in difficulties on their
> corporate intranet sites due to this change. The release notes should
> mention it.

The users must set the preference network.negotiate-auth.allow-insecure-ntlm-v1 to true.
Here are a post about it.
Flags: needinfo?(lsblakk)
Fixing the confusing bug summary...
Summary: Firefox enables insecure NTLM (pre-NTLMv2) authentication → Disable insecure NTLMv1 authentication
Depends on: 1023748
Thanks :lsblakk. Based on my research, this is the top compatibility issue of Firefox 30.

https://docs.google.com/spreadsheets/d/1048AVpvbP3O2atsV3i--xLpHCr4PR7TGXyFtgMrvt6Q/edit#gid=89642089
Wondering what would be simpler: impl NTLMv2 (we may have some resources for this) or have an "override" page as in case of cert errors with the decision being persisted.  Something similar have been considered for RC4 ciphers.
An override is probably going to be simpler but it is not the technically correct solution and it is certainly more jarring to end users.

Google's Chrome has the same issue but they still implement NTLMv1 support, perhaps you could collaborate there if the decision is made to implement it?

"Remaining work

Support NTLMv2 on Mac and Linux. Our portable NTLM code supports NTLMv1 only."

http://www.chromium.org/developers/design-documents/http-authentication
(In reply to Honza Bambas (:mayhemer) from comment #50)
> Wondering what would be simpler: impl NTLMv2 (we may have some resources for
> this) or have an "override" page as in case of cert errors with the decision
> being persisted.  Something similar have been considered for RC4 ciphers.

Or at least an easy-to-understand error page. Users will be surely confused to see a blank page, as reported in Bug 1023748 and other feedbacks. Until such a solution is implemented, Firefox should probably flip the allow-insecure-ntlm-v1 preference (with Firefox 30.0.1 if available).
(In reply to Kohei Yoshino [:kohei] from comment #52)
> (In reply to Honza Bambas (:mayhemer) from comment #50)
> > Wondering what would be simpler: impl NTLMv2 (we may have some resources for
> > this) or have an "override" page as in case of cert errors with the decision
> > being persisted.  Something similar have been considered for RC4 ciphers.
> 
> Or at least an easy-to-understand error page. Users will be surely confused
> to see a blank page, as reported in Bug 1023748 and other feedbacks. Until
> such a solution is implemented, Firefox should probably flip the
> allow-insecure-ntlm-v1 preference (with Firefox 30.0.1 if available).

There is another smarter alternative too if-and-until an internal NTLMv2 implementation is available:

Always allow NTLMv1 where the connection is over SSL/TLS as there is no vulnerability here, where it is not defer to the allow-insecure-ntlm-v1 preference and leave this disabled by default.

Nick
(In reply to Kohei Yoshino [:kohei] from comment #52)
> Or at least an easy-to-understand error page. 

This is a server fault.  The server has to reply with a 401 page and explain, Firefox is not obligated to (and cannot even do) anything more here.

> Users will be surely confused
> to see a blank page, as reported in Bug 1023748 and other feedbacks. Until
> such a solution is implemented, Firefox should probably flip the
> allow-insecure-ntlm-v1 preference (with Firefox 30.0.1 if available).

Definitely not.  NTLMv1 is practically same as a plain text basic authentication where the password flies on the wire unencrypted.

Problem here is - and I repeat my self - that NTLMv1 gives a false sense of security.

(In reply to Nick Lowe from comment #53)
> There is another smarter alternative too if-and-until an internal NTLMv2
> implementation is available:
> 
> Always allow NTLMv1 where the connection is over SSL/TLS as there is no
> vulnerability here, where it is not defer to the allow-insecure-ntlm-v1
> preference and leave this disabled by default.
> 
> Nick

This actually may not be that bad idea.  I will think of this and file a bug.  Thanks.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #0)
> +++ This bug was initially created as a clone of Bug #423758 +++
> 
> > NTLM Compatibility Levels
> > http://msdn2.microsoft.com/en-us/library/cc207934.aspx
> > http://davenport.sourceforge.net/ntlm.html#ntlmVersion2
> 
> Recently it has been discovered that NTLM before NTLMv2 is basically
> completely insecure. So, we should disable all pre-v2 NTLM support.
> 
> Note that we don't support NTLMv2 on all platforms yet: see bug 423758. That
> said, I am not sure that we need to block this on fixing bug 423758.

I take issue with this statement.  NTLM is no less secure than plaintext authentication, and LM is already off by default.  Yes, NTLMv2 is better, and I'm working on that, but NTLM, particularly when NTLM2 session security is used, is a reasonable authentication scheme that Windows servers accept when they won't accept plaintext authentication. 

There is no UI difference that I can see between our NTLMv1 prompt and a basic authentication prompt, so the user is not under any false sense of security, they just want to get in to their intranet site.  As long as we allow basic auth, NTLMv1 is no worse choice. 

In environments where challenge-response (rather than plaintext or tunneled plaintext) authentication is the norm, such as in a VPN or in other protocols, then this change might make sense, but while waiting for my NTLMv2 work, I can only advise to revert this ill-considered commit.

Andrew Bartlett
(Authentication Developer, Samba Team)
(In reply to Andrew Bartlett from comment #55)
> Yes, NTLMv2 is better,
> and I'm working on that, but NTLM, particularly when NTLM2 session security
> is used, is a reasonable authentication scheme that Windows servers accept
> when they won't accept plaintext authentication. 

Neither NTLMv1 or plaintext (basic) are reasonable forms of authentication though where security is expected, so I do not think this follows logically. The difference between the two forms is that one is by nature that way, the other purports to offer security and does not.

> There is no UI difference that I can see between our NTLMv1 prompt and a
> basic authentication prompt, so the user is not under any false sense of
> security, they just want to get in to their intranet site.  As long as we
> allow basic auth, NTLMv1 is no worse choice. 

The logic that flows from this would surely only be to further change the UI when basic auth is used outside the protection of SSL/TLS to make it more clear that the authentication is inherently not secure, not to allow NTLMv1 to be used by default in the same scenario.

> In environments where challenge-response (rather than plaintext or tunneled
> plaintext) authentication is the norm, such as in a VPN or in other
> protocols, then this change might make sense, but while waiting for my
> NTLMv2 work, I can only advise to revert this ill-considered commit.

I respectfully disagree. Because of the demonstrable security weaknesses of NTLMv1, it should be disabled by default when used outside of SSL/TLS because of the expectations placed on it and its common use cases. Administrators are aware of the inherent insecurity of basic authentication which is by its nature but not so for NTLMv1 which only gives a false sense of security.

A working NTLMv2 implementation for Firefox would and will be absolutely fantastic btw, huge, huge thanks for working on one! :)
(In reply to Nick Lowe from comment #56)
> (In reply to Andrew Bartlett from comment #55)
> > Yes, NTLMv2 is better,
> > and I'm working on that, but NTLM, particularly when NTLM2 session security
> > is used, is a reasonable authentication scheme that Windows servers accept
> > when they won't accept plaintext authentication. 
> 
> Neither NTLMv1 or plaintext (basic) are reasonable forms of authentication
> though where security is expected, so I do not think this follows logically.
> The difference between the two forms is that one is by nature that way, the
> other purports to offer security and does not.

Where do we purport to offer security in this area?  

> > There is no UI difference that I can see between our NTLMv1 prompt and a
> > basic authentication prompt, so the user is not under any false sense of
> > security, they just want to get in to their intranet site.  As long as we
> > allow basic auth, NTLMv1 is no worse choice. 
> 
> The logic that flows from this would surely only be to further change the UI
> when basic auth is used outside the protection of SSL/TLS to make it more
> clear that the authentication is inherently not secure, not to allow NTLMv1
> to be used by default in the same scenario.

It would be better to have good UI around plaintext authentication, either basic or forms-based, and I'm fine with NTLMv1 triggering the same UI, but I don't see the logic flow you suggest.

> > In environments where challenge-response (rather than plaintext or tunneled
> > plaintext) authentication is the norm, such as in a VPN or in other
> > protocols, then this change might make sense, but while waiting for my
> > NTLMv2 work, I can only advise to revert this ill-considered commit.
> 
> I respectfully disagree. Because of the demonstrable security weaknesses of
> NTLMv1, 

What, in your view, is that specifically?

> it should be disabled by default when used outside of SSL/TLS
> because of the expectations placed on it and its common use cases.
> Administrators are aware of the inherent insecurity of basic authentication
> which is by its nature but not so for NTLMv1 which only gives a false sense
> of security.

It sounds like we are targeting the web server administrators here, by proxy of their Linux users.  This seems counter-productive and indirect, and given the tiny market share we are discussing, it only hurts us. 

> A working NTLMv2 implementation for Firefox would and will be absolutely
> fantastic btw, huge, huge thanks for working on one! :)

Thanks,

Andrew Bartlett
You need to log in before you can comment on or make changes to this bug.