[plug] Samba And Windows

[Richard Sharpe]

At 05:47 PM 7/20/00 +0800, you wrote:
>On Thu, Jul 20, 2000 at 05:12:27PM +0800, Steve Baker wrote:
> 
>> Probably a password encryption problem.  NT/2000 encrypt the passwords,
>> 95/98 do not.  There are some readme's in the samba docs that tell you all
>> about it, and how to either turn the encryption off (bad) or get samba to
>> work with them (good).

Unlikely to be a password encryption problem given the description, unless
the plaintext password hack has been applied to Win98 and not Win2K!

>Wasn't this the Microsoft protocol where a hash of the password became
>the authentication token itself?

No! This is inherited from IBM. There are two different password hashes,
LMhash and NThasn (well, three now, as Win2K uses a stronger hash, as well,
IIANM).

The following are some words I wrote for another list and paraphrase what I
wrote for Special Edition, Using Samba:

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.


>  In such a case hashing brings almost
>no security whatsoever and you may as well not have "encrypted"
>passwords at all.  (This may not be the same protocol or they may have
>fixed it but I've got a feeling it is.)  BTW, I also think that 95/98
>use some "encryption" scheme too because I remember reading about it
>when I set up a Linux box to do file serving to two 95 machines a couple
>of years ago.  Perhaps 2000 uses a different system or protocol though.
>
>It's also funny how people (not you in particular, people in general)
>like to equate cryptography with security.  "Encryption good,
>non-encryption bad."  At the end of the day cryptography *can* bring
>security but the security of the overall system has more to do with the
>way it's implemented and used rather than the presence or absence of
>cryptography.  Sometimes cryptography can make a badly implemented or
>used system actually less secure.
>
>Regards,
>
>Christian.
>
>

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