Are these that much of a security risk that I should go to the trouble of disabling them?
Printable View
Are these that much of a security risk that I should go to the trouble of disabling them?
The effect of LM hashes is to make cracking your SAM (or Active Directory? Does AD even have them?) much easier.
Fortunately, the SAM can only be attacked if a user can get physical access to the machine or gain administrator or localsystem privileges remotely somehow. This you should hope doesn't happen, as your security would then be compromised anyway.
Another possible effect is to make password brute-forcing over the network easier. But not much easier, because with sensible (perhaps default) timing settings, it should still take a long time to guess a decent password.
I don't think it could hurt, as the LM hashes are only there to support exceptionally elderly clients - check though if you're using something like Microsoft Client for DOS that it supports NT hashes otherwise you might end up locking out your DOS clients (I have seen some companies who use DOS boot discs to image machines over the network, for example)
You should definitely test what effect it would have before disabling them network-wide, as it has a (small) chance of locking some people out. I don't know whether you can re-enable them once they're disabled. Certainly if these LM hashes were disabled, and then re-enabled, users who want to use then would have to be issued with new passwords.
Slarty
The LMHash is a hash of the users password stored in LM (crap) form. It would be quite easy to place a LMsniffer to collect the hashes then run a dictionary through a lmhash program (I believe Samba comes with one, if not I've seen perl scripts to do it) Then compare your hashed dictionary to the sniffed hashes. LM makes this a much more dangerous attack by sucking so bad. (Each password is really two separate 7 byte hashes which are first turned into uppercase and then padded with 0's, oh yeah and no salt) . If you do not need the backwards compatability feature of LM (ie no Win 3.1,95,98) then I would disable it as LM hashes present one of the larger holes in MS security. Be advised however that disabling LM auth in your SecPolicy will not prevent a LM hash from being stored in the SAM (not on 2000 anyway) so as slarty mentioned anyone able to retrieve the SAM will have a much easier time of cracking the password by working on the LM hashes.
-Maestr0
Thank you for the input. So setting nolmhash in the registry to a value of 1 should fix the problem and i should not have to worry about this type of intrusion attempt on my computer?
(I am not worried about any compatibility issues as this is just my home desktop computer)
Bear in mind that disabling the LM hashes only makes it harder to crack the hashes, not impossible.
In fact dictionary attacks are still quite easy if the users use an easy to guess password.
You should use a fairly complex password and have failed logon auditing enabled, and limit the speed that guesses can be made (I think that NT may do this by default)
Slarty
I agree with slarty. And really no matter how tough the password, running on a P4 w/ LC4 will crack any password in a matter of days. The main goal for any administrator should be to prevent an attacker from getting SAM, period. (which is hard I know) Because once they get it, there is no stopping them, atleast with todays encryption standards.
For instance a relatively hard password: "toc1uruk" took only about 2 hours to crack.
I dont think cracking passwords is quite as fast as you imagine. LC4 can crack any LM hash in a short time (because LM sucks, blame IBM thats what MS did) but if you want a NTLMv2 password back- well, I saw a 16 node beowulf cluster in Japan that said they could have it in 21 months or so for an 8 character alpha/numeric password (NO special characters), wonder how much that'd cost?
-Maestr0
How might I go about doing this?Quote:
and have failed logon auditing enabled, and limit the speed that guesses can be made
This can be done in (2k/XP) from the Control Panel>Administrative Tools>Local Security Settings>Local Policies>Audit Policy
-Maestr0
And to limit the amount of tries someone can do you can adjust the password policy to lockout the account after 3-5 tries and leave it locked out for 15-60 minutes.