Disable LMv1 hash by default

RESOLVED FIXED in mozilla1.8beta2

Status

()

P1
normal
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: darin.moz, Assigned: darin.moz)

Tracking

Trunk
mozilla1.8beta2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.14 ?
blocking-aviary1.0.9 ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

15 years ago
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.
(Assignee)

Updated

15 years ago
Blocks: 250014
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
(Assignee)

Updated

14 years ago
Priority: -- → P1
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2
(Assignee)

Updated

14 years ago
Blocks: 254365
(Assignee)

Comment 1

14 years ago
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.
(Assignee)

Comment 2

14 years ago
Posted patch v1 patchSplinter Review
Attachment #180836 - Flags: review?(cneberg)
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?
(Assignee)

Comment 4

14 years ago
> 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 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.
Attachment #180836 - Flags: review?(cneberg) → review+
(Assignee)

Comment 6

14 years ago
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 ;-)
(Assignee)

Updated

14 years ago
Attachment #180836 - Flags: superreview?(bryner)

Comment 7

14 years ago
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 :-)
(Assignee)

Comment 8

14 years ago
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

14 years ago
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 :-)
Attachment #180836 - Flags: superreview?(bryner) → superreview+
(Assignee)

Comment 10

14 years ago
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.
Attachment #180836 - Flags: approval1.8b2?
Attachment #180836 - Flags: approval-aviary1.1a1?
Comment on attachment 180836 [details] [diff] [review]
v1 patch

a=asa
Attachment #180836 - Flags: approval1.8b2?
Attachment #180836 - Flags: approval1.8b2+
Attachment #180836 - Flags: approval-aviary1.1a1?
(Assignee)

Comment 12

14 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
This probably ought to have been back-ported to the aviary1.0 branch (see bug 254365)
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
(Assignee)

Updated

13 years ago
Attachment #180836 - Flags: approval1.7.14?
Attachment #180836 - Flags: approval-aviary1.0.9?
You need to log in before you can comment on or make changes to this bug.