Password sync

[Richard Sharpe]

At 05:39 PM 7/20/00 +1000, Simo Sorce wrote:
>Jeremy Allison wrote:
>> 
>> Paul J Collins wrote:
>> 
>> > NT's password format is neither insecure nor trivial.  It is a one-way
>> > hash.
>> 
>> This is true, but the implementation is badly flawed.
>> There is no salt - meaning if two users pick the same
>> password it will be an identical hash.
>> 
>> The second problem is not the NT password hash but the
>> legacy lanman hash which is usually stored with the
>> more secure NT hash.
>> 
>> The lanman hash *is* trivial and brute forcible, and
>> this makes the security of the NT hash irrelevent, as
>> you only need to brute force the lanman one.
>> 
>Correct me if I'm wrong.

OK :-)

>The problem is not only the Lm hash.
>The problem is that what goes on the network is the hash (NT hash, LM
>hash it does not matter).

No, the hash does not go over the network. The IBM folks who designed this
stuff were not that stupid.

It is a challenge/handshake style protocol. When the client does a negprot,
and the server handled Encrypted passwords, the server returns a randomly
chosen challenge.

When the client authenticates, it uses the {NT,LM}hash to encrypt the
challenge using DES. Unfortunately, the LMhash is very weak, and the
encryption of the challenge continues that weakness.

The LM hash is computed by taking the user's password, extending to 14
chars if  needed with NUL, and splitting into two 56-bit keys. These 56-bit
keys then encrypt the string !@#$%KGS, and the results are packed back into
a 128-bit field.  This can be brute forced.  The NThash is much stronger,
being an MD4 hash of the user's password.

The response above is calculated by taking the {LM,NT}hash above, extending
to 21 bytes with NUL, splitting into three 56-bit keys, and encrypting the
challenge in succession and concatenating the result into a 24-byte field,
which is returned.

As you can see, not that secure, and the LMhash is no where near as secure
as a 14-char password could be.

The details for brute-forcing the LMhash can be found on www.l0pht.com.

>And this is check against the stored hash to check they are equal.
>Now I have a switched network and my smbpasswd is not readable, but if
>someone get the hands on a username/hash pair how much time do you thimk
>it will need to patch samba to accept as parameter the hash an use it
>directly instead of the password.
>In this scenario I does not even need to know the password, I HAVE A
>CLEAR PASSWORD EQUIVALENT.
>
>Again, Correct me if I'm wrong, meanwhile I never store sensitive data
>on CIFS/SMB reacheable machines.
>
>If there anyone interested, is there anyone working or knowing a method
>to replace msgina.dll (the module that do the authentication method) to
>use with samba PDC and that does not break Domain/Profiles/Permissions
>behaviours?
>I've tested nisgina but as my users really leaps from a machine to
>another any time It will not work very well (and I do not like much
>plain NIS as well 8] ).
>
>Regards,
>Simo.
>
>-- 
>Simo Sorce - Integrazione Sistemi Unix/Windows - Politecnico di Milano
>E-mail: simo.sorce at polimi.it
>Tel.int: 02 2399 2425 - Fax.int. 02 2399 2451
>-----------------------------------------------------------------
>Be happy, use Linux!
>

Regards
-------
Richard Sharpe, sharpe at ns.aus.com
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba