250691 - Disable LMv1 hash by default

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[Darin Fisher]

Disable LMv1 hash by default.  Allow it to be enabled via a hidden pref.

See bug 231529 comment #28 for justification.  Exerpt here:

Andrew Bartlett wrote:
> For a site to only have an LM password on record means that they:
> - Cannot use NTLM2, and must have specificly configured all member servers, 
>   and proxies etc not to negotiate use of it
>
> - Must have changed that user's password from a Win95 machine, with a
>   particularly old password change call.
>or
> - Must never have changed that password since running 'Lan Manager' 10 years
>ago (or for Samba PDCs, since running a very old version of Samba).
>
>I think it's safe to assume the presence of the NT password hash.

Comment 1

[Darin Fisher]

According to http://davenport.sourceforge.net/ntlm.html#ntlmVersion2, the
correct way to only send a NTLM hash is to send it in both the LM and NTLM
response fields.

Comment 2

[Darin Fisher]

Attachment: v1 patch

Comment 3

[Christopher Nebergall]

No matter what the setting of this value, the SSPI on Windows may still use the
LM Hash if the registry is not changed correct?
(http://support.microsoft.com/kb/q147706/) Not sure what to do about this, but
it is at least worth a comment in with the prefs.

Do we currently only use the SSPI for auto sending authentication, and the built
in NTLM if the user is actually prompted for a password?

Comment 4

[Darin Fisher]

> No matter what the setting of this value, the SSPI on Windows may still use 
> the LM Hash if the registry is not changed correct?

Right


> it is at least worth a comment in with the prefs.

Agreed


> Do we currently only use the SSPI for auto sending authentication, and the 
> built in NTLM if the user is actually prompted for a password?

Yup, this is the only saving grace.  The goal is to prevent the default
configuration from sending LM hashes to origin servers.  Users would have to
change prefs to get LM hashes (either by enabling automatic NTLM or by setting
the send-lm-hash pref).

Comment 5

[Christopher Nebergall]

Comment on attachment 180836 [details] [diff] [review]
v1 patch

Looks fine.  Please add a comment in the prefs about SSPI still being able to
use LM.  

If you ever plan on supporting NTLM V2, you may want to consider changing the
pref type to something besides boolean for forward compatiblility. (like
network.ntlm.min_version  and have 0 represent LM, and 1 NTLM V1, and someday 2
be NTLM V2, a high number would effectively disable NTLM support). 

But if that isn't going to happen any time soon then skip it.

Comment 6

[Darin Fisher]

yeah, i thought about adding a pref like that.  i don't have any plans to
implement NTLM v2, but maybe someone will.  we may actually want a pref that
mimics the values defined by microsoft for that registry key ;-)

Comment 7

[Andrew Bartlett]

My only nitpick is that this regards the return of what I call (in line with the
most sane pattern of description I could find) the 'LM response', not the LM hash.  

I call the password equivilant value shared by both parties (the value on record
with the server) the LM hash, while what we send to the server over the network
is the 'LM response'.  

The LM response is not enough to simply replay, as this is a challenge-response
system, but may be reversed with less than extordinary effort, and less effort
than the NT response.

See also http://www.ubiqx.org/cifs/SMB.html#SMB.8 for this subject in painful
detail :-)

Comment 8

[Darin Fisher]

Andrew: I'm not quite sure what problem you are nit-picking.  Are you saying
that the pref should be renamed to "network.ntlm.send-lm-response" instead of
what it currently is?  Or, are you talking about something else in
nsNTLMAuthModule.cpp?

Comment 9

[Andrew Bartlett]

Sorry - clearly my comment was made too early in the morning :-)

I am just suggesting a change in preference name, in line with standard
conventions.  There is too much confusion in NTLM already :-)

Comment 10

[Darin Fisher]

Comment on attachment 180836 [details] [diff] [review]
v1 patch

I'd like to get this patch in for Firefox 1.1a if possible to maximize feedback
from testers.

Comment 11

[Asa Dotzler [:asa]]

Comment on attachment 180836 [details] [diff] [review]
v1 patch

a=asa

Comment 12

[Darin Fisher]

fixed-on-trunk (for firefox 1.1a -- let's see what kind of feedback we get!)

the only change to the pref was a renaming of send-lm-hash to send-lm-response
as discussed above.

Comment 13

[Daniel Veditz [:dveditz]]

This probably ought to have been back-ported to the aviary1.0 branch (see bug 254365)