LMOWFv1 with passwords > 14 chars

[jborean93]

The MS-NLMP docs define the LMOWFv1 function as

 Define LMOWFv1(Passwd, User, UserDom) as
        ConcatenationOf( DES( UpperCase( Passwd)[0..6],"KGS!@#$%"),
                  DES( UpperCase( Passwd)[7..13],"KGS!@#$%")) 

It also states that

Password of the user. If the password is longer than 14 characters, the LMOWF v1 cannot be computed. For LMOWF v1, if the password is shorter than 14 characters, it is padded by appending zeroes.

While this is correct for LM hash authentication, this hash is still computed even if NTv1 hashes are used stopping longer passwords being used for NTv1. The check here will block the initiator from acquiring a credential even if they want to use just NTv1 and not LMv1 authentication.

[simo5]

The question is what to do in KXKEY is extended security is not negotiated, I am preparing a tentative patch for this case.

[simo5]

I have two options here: https://github.com/simo5/gssntlmssp/tree/nolmkey1 and https://github.com/simo5/gssntlmssp/tree/nolmkey2

I have a feeling #2 is the way to go as that what windows machines have at hand after local authentication (or in the DCs).

@jborean93 what do you think?

[jborean93]

I think 2 makes more sense as well, if a user's password is greater than 14 characters then LM auth will never work even if the server is set to store the LM hash. It's also a less invasive change than option 1, I would only suggest having a comment saying why the LM hash is 0'd out.

[simo5]

done PTAL