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.

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.

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?

> 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.

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 ;-)

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 :-)

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?

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 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 on attachment 180836 [details] [diff] [review] v1 patch a=asa

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.

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