Disabling LM Hash creation

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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


On Wed, 29 Sep 2004 11:05:26 +0100, rusga <reply2newsgroup@nntp> wrote:

Oops! That's it.

I'll try it and post back.

Thank you,
rusga

On Thu, 30 Sep 2004 02:39:31 -0700, Mark V <notvalid@nul.invalid> wrote:

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

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

"rusga" wrote:

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

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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


"rusga" <reply2newsgroup@nntp> wrote in message
newspse3bf0qjeqwqha@207.46.248.16...
> 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
>
>
> On Wed, 29 Sep 2004 11:05:26 +0100, rusga <reply2newsgroup@nntp> wrote:
>
> Oops! That's it.
>
> I'll try it and post back.
>
> Thank you,
> rusga
>
> On Thu, 30 Sep 2004 02:39:31 -0700, Mark V <notvalid@nul.invalid> wrote:
>
> 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

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Can anyone test this?

Regards,
rusga


On Thu, 30 Sep 2004 09:05:01 -0700, <Karl Levinson [x y]> wrote:

>
>
> "rusga" wrote:
>
>> .... 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.
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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


On Thu, 30 Sep 2004 15:56:10 GMT, Steven L Umbach
<n9rou@n0-spam-for-me-comcast.net> wrote:

> 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
>
>
> "rusga" <reply2newsgroup@nntp> wrote in message
> newspse3bf0qjeqwqha@207.46.248.16...
>> 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
>>
>>
>> On Wed, 29 Sep 2004 11:05:26 +0100, rusga <reply2newsgroup@nntp> wrote:
>>
>> Oops! That's it.
>>
>> I'll try it and post back.
>>
>> Thank you,
>> rusga
>>
>> On Thu, 30 Sep 2004 02:39:31 -0700, Mark V <notvalid@nul.invalid> wrote:
>>
>> 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
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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


"rusga" <reply2newsgroup@nntp> wrote in message
newspsfaetdtteqwqha@207.46.248.16...
> 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
>
>
> On Thu, 30 Sep 2004 15:56:10 GMT, Steven L Umbach
> <n9rou@n0-spam-for-me-comcast.net> wrote:
>
>> 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
>>
>>
>> "rusga" <reply2newsgroup@nntp> wrote in message
>> newspse3bf0qjeqwqha@207.46.248.16...
>>> 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
>>>
>>>
>>> On Wed, 29 Sep 2004 11:05:26 +0100, rusga <reply2newsgroup@nntp> wrote:
>>>
>>> Oops! That's it.
>>>
>>> I'll try it and post back.
>>>
>>> Thank you,
>>> rusga
>>>
>>> On Thu, 30 Sep 2004 02:39:31 -0700, Mark V <notvalid@nul.invalid> wrote:
>>>
>>> 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
>>
>>
>

 

[Jonathan]

Archived from groups: microsoft.public.win2000.security (More info?)

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.


"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
news:urk8d.328938$Fg5.224436@attbi_s53...
> 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
>
>
> "rusga" <reply2newsgroup@nntp> wrote in message
> newspsfaetdtteqwqha@207.46.248.16...
> > 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
> >
> >
> > On Thu, 30 Sep 2004 15:56:10 GMT, Steven L Umbach
> > <n9rou@n0-spam-for-me-comcast.net> wrote:
> >
> >> 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
> >>
> >>
> >> "rusga" <reply2newsgroup@nntp> wrote in message
> >> newspse3bf0qjeqwqha@207.46.248.16...
> >>> 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
> >>>
> >>>
> >>> On Wed, 29 Sep 2004 11:05:26 +0100, rusga <reply2newsgroup@nntp>
wrote:
> >>>
> >>> Oops! That's it.
> >>>
> >>> I'll try it and post back.
> >>>
> >>> Thank you,
> >>> rusga
> >>>
> >>> On Thu, 30 Sep 2004 02:39:31 -0700, Mark V <notvalid@nul.invalid>
wrote:
> >>>
> >>> 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
> >>
> >>
> >
>
>