Disabling LM Hash creation

[rusga]

Hi,

I've pasted this followup here since it's the proper NG to do so.
It's named "Disabling LM Hash creation" in
microsoft.public.win2000.registry.

(paste start)

Ok...

What I did was:

a) Changed the key to "NoLMHash" (no spaces).
b) Rebooted the system.
c) Changed the passwords.
d) Tried to crack them with LC4.

.... the setting was now active, but according to LC4, what happened was:

a) The LM and NTLM passwords changed to an *empty* state to all users
afected.
b) The LM and NTLM hashes *were created anyway*.
c) The LM and NTLM hashes were *the same for all users* afected (same
empty seed).

Now, these few questions arise:

a) Isn't this a worse security scenario?
b) Shouldn't the key be renamed to "Blank_LM/NTLM_Passwords" (or the like)?
c) Am I seeing it wrongly?

Regards,
rusga



Oops! That's it.

I'll try it and post back.

Thank you,
rusga


In microsoft.public.win2000.registry rusga wrote:

Hi,

In MS checklist
( http://207.46.156.156/technet/images/security/prodtech/win2000/wi
n2khg/images/win2k45_BIG.gif ) there's the possibility of
disabling the creation of LM hashes by creating the folowing new
key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\NoLM Hash

.... but, unfortunately, it doesn't seem to work since LC4 cracker
still get's them.

What am I doing wrong here?

I think the KeyName is: NoLMHash
If you had a SPACE in there (as did your cited (but incorrect)
article) it would fail.

There is a Group Policy that would probably be better and easier to
use.
KBA 299656
"How to prevent Windows from storing a LAN manager hash of your
password in Active Directory and local SAM databases"

(paste end)

Regards,
rusga

 

[Steven L Umbach]

I use Cain and Abel and my experience is that after disabling lm hash and
resetting the passwords that the passwords are much more difficult to crack.
Try this with lm hash disabled. Change a password to some thing like aT184
!*ir&h and see how long it takes to recover that password. --- Steve

 

[Guest]

.... the setting was now active, but according to LC4, what happened was:

a) The LM and NTLM passwords changed to an *empty* state to all users
afected.
b) The LM and NTLM hashes *were created anyway*.
c) The LM and NTLM hashes were *the same for all users* afected (same
empty seed).

Now, these few questions arise:

a) Isn't this a worse security scenario?

No, not if you can't use those hashes to log in. If there was a way to use
those hashes [like if an attacker was somehow able to change that registry
value back and reboot the machine, and if this allowed you to log in using
blank passwords], then I suppose that could be a problem. But it remains to
be seen whether that scenario is even possible, and even if it was, you would
probably need to somehow gain administrator privileges to change that
registry value, at which point you already own the machine anyways without
needing to reboot.

b) Shouldn't the key be renamed to "Blank_LM/NTLM_Passwords" (or the like)?

If you did, you'd cause backwards compatibility issues and have problems
with consistency when templates for one OS is accidentally applied to other
OSes. Unfortunately there are a lot of registry values with cryptic or
misleading names. Keeping registry value names short might help keep the
registry smaller, which might help enhance performance. The NoLMHash name
might still be accurate if this value makes it so that no valid LM hashes can
be used or cracked.

 

[rusga]

Can anyone test this?

Regards,
rusga

.... the setting was now active, but according to LC4, what happened
was:

a) The LM and NTLM passwords changed to an *empty* state to all users
afected.
b) The LM and NTLM hashes *were created anyway*.
c) The LM and NTLM hashes were *the same for all users* afected (same
empty seed).

Now, these few questions arise:

a) Isn't this a worse security scenario?

No, not if you can't use those hashes to log in. If there was a way to
use
those hashes [like if an attacker was somehow able to change that
registry
value back and reboot the machine, and if this allowed you to log in
using
blank passwords], then I suppose that could be a problem. But it
remains to
be seen whether that scenario is even possible, and even if it was, you
would
probably need to somehow gain administrator privileges to change that
registry value, at which point you already own the machine anyways
without
needing to reboot.

b) Shouldn't the key be renamed to "Blank_LM/NTLM_Passwords" (or the
like)?

If you did, you'd cause backwards compatibility issues and have problems
with consistency when templates for one OS is accidentally applied to
other
OSes. Unfortunately there are a lot of registry values with cryptic or
misleading names. Keeping registry value names short might help keep the
registry smaller, which might help enhance performance. The NoLMHash
name
might still be accurate if this value makes it so that no valid LM
hashes can
be used or cracked.

 

[rusga]

That's an hard one anyway...
Maybe it should be tested with <8 chars password.
On their site, MS states that this was ªNOT* tested.
(There's something fishy with that *empty* state...)

Regards,
rusga

 

[Steven L Umbach]

I actually tested using the same password for both lm and ntlm. While I
cracked the password in fifteen minutes or less, after disabling lm and
resetting the password to the same password I gave up trying after it was
still trying brute force crack overnite. --- Steve

 

[Jonathan]

Programs like LC will still crack the NTLM passwords if you disable the LM
password side of things.

What the progams like LC actually do is crack the LM password first, say
getting the result PASSWORD1, it then uses this password and cracks the NTLM
hash using the LM password, it can then crack the 'real' password i.e.
Password1 much quicker, it does this because even though the passwords are
the same 'word' NTLM uses the different cases, cracking the case-insensitive
LM hash is quicker, they then use the 'word' to crack the NTLM hash by
trying all the possibilities of the character combinations in the word,
which is why you see it taking longer to crack the NTLM password by itself.

Jonathan.

I actually tested using the same password for both lm and ntlm. While I
cracked the password in fifteen minutes or less, after disabling lm and
resetting the password to the same password I gave up trying after it was
still trying brute force crack overnite. --- Steve

That's an hard one anyway...
Maybe it should be tested with <8 chars password.
On their site, MS states that this was ªNOT* tested.
(There's something fishy with that *empty* state...)

Regards,
rusga

I use Cain and Abel and my experience is that after disabling lm hash and
resetting the passwords that the passwords are much more difficult to
crack.
Try this with lm hash disabled. Change a password to some thing like
aT184
!*ir&h and see how long it takes to recover that password. --- Steve


Hi,

I've pasted this followup here since it's the proper NG to do so.
It's named "Disabling LM Hash creation" in
microsoft.public.win2000.registry.

(paste start)

Ok...

What I did was:

a) Changed the key to "NoLMHash" (no spaces).
b) Rebooted the system.
c) Changed the passwords.
d) Tried to crack them with LC4.

... the setting was now active, but according to LC4, what happened was:

a) The LM and NTLM passwords changed to an *empty* state to all users
afected.
b) The LM and NTLM hashes *were created anyway*.
c) The LM and NTLM hashes were *the same for all users* afected (same
empty seed).

Now, these few questions arise:

a) Isn't this a worse security scenario?
b) Shouldn't the key be renamed to "Blank_LM/NTLM_Passwords" (or the
like)?
c) Am I seeing it wrongly?

Regards,
rusga

Oops! That's it.

I'll try it and post back.

Thank you,
rusga