[plug] Samba And Windows

Michael De Santis michael at harvestroad.com.au
Fri Jul 21 13:19:29 WST 2000


Thanks for all the replies on my initial post. I have resolved the
problem my Samaba problem.

Michael



Richard Sharpe wrote:
> 
> 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

-- 
Michael De Santis                        michael at harvestroad.com
Systems Administrator                    Harvestroad Limited 

                 http://www.harvestroad.com



More information about the plug mailing list