Password encryption in 2.2.0

[Michael B. Allen]

On Sat, Apr 28, 2001 at 11:11:55AM +0900, Richard Sharpe wrote:
> jam002:8663:9C6602D2622F49641664635A22D01271:617B07A0803FA6981960CADCAA059CF
> 3:[U
> >> >           ]:LCT-3AE6E102:
> >>
> >> Just out of curiosity, if this is the LANMAN hash, how do you compare
> >> for equality when the client response could be different due to the
> >> factoring in of the challenge key?
> >
> >huh?  The hashed password acts as the 3x56bit DES keys (after adding
> >on 5 bytes of NULL) for the generating the response.  Did I
> >misunderstand your question?
> 
> Michael, What Jerry is saying is that the hashs are not sent over the wire.
> They are used as the key, after adding a few bytes, to encrypt the challenge.
> 
> If the hash the client has matches the hash the server has, they will each
> compute the exact same response, and the user has proven s/he is who s/he
> claims to be (modulo disclosure of the password).

Actually I think I understand. If the algo is:

P24 = E(MD4(U(PN) + 5 NULLs, C8))

Then your just doing the:

MD4(U(PN) + 5 NULLs

part first and that's whats in the smbpassword file? For some reason I
was thinking there was no way to get the P24 to compair without rehashing
plaintext with the new challange in which case you would have no other
choice but to store plain text. But I see now there's an intermediate
hash that does NOT depend on C8.

Thanks. Sorry for the bother. Nothing to see here. Moving on :~)
Mike

-- 
signature pending