[jcifs] Passwords longer than 14 characters [PATCH]

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Zalewski, Michael J (Michael)** CTR ** [SMTP:mjzalewski at lucent.com]
> Sent:	Tuesday, April 09, 2002 8:51 PM
> To:	jcifs at lists.samba.org
> Subject:	RE: [jcifs] Passwords longer than 14 characters [PATCH]
> 
> Thanks for this information. I was able to make a patch which resolves the
> problem
> 
>     static byte[] getPreNTLMResponse( String password, byte[] challenge ) {
>         byte[] p14 = new byte[14];
>         byte[] p21 = new byte[21];
>         byte[] p24 = new byte[24];
>  
> +       // Only encrypt the first 14 bytes of the password for Pre 0.12 NT
> LM
> +       byte[] passwordBytes = password.toUpperCase().getBytes();
> +       int passwordLength = passwordBytes.length;
> +       if( passwordLength > 14) {
> +           passwordLength = 14;
> +       }
> .       System.arraycopy( passwordBytes, 0, p14, 0, passwordLength );
>         E( p14, S8, p21);
>         E( p21, challenge, p24);
>         return p24;
>     }
> 
> When I built JCIFS with this patch, I was able to successfully verify a file
> with a long password.
> 
	Great! Patch accepted and thanks!

> 1) You have to look at the length of password.toUpperCase().getBytes().
> There could possibly be double-byte characters in the password.
> 2) This works because the two responses are both sent in the packet by
> SmbComSessionSetupAndX.writeParameterWordsWireFormat. The response sent will
> include the digests computed by SmbSession.getPreNTLMResponse, followed by
> SmbSession.getNTLMResponse.
> Apparently, if the resource is protected by a server running Pre NT LM, the
> first response is used. If the server is running NT LM 0.12 or higher, the
> second response is used. Maybe the first response is even ignored.
> 3) I think I read somewhere that the limit for NT passwords is 255 bytes (if
> two byte characters are used, the limit is less than 255 characters). The
> Windows 2000 dialog to change your password allows you to input
> approximately 160 characters.
> 
> 4) One question. The spec says that in pre 0.12 NT LM, the server and client
> should compute a response based on
> 
> >  o P14 is a 14 byte string containing the user's password in clear
> >     text, upper cased, padded with spaces
> 
> In the above code, P14 would be null (0) padded. This may not be correct, so
> the response computed by SmbSession.getPreNTLMResponse may not be correct.
> But most servers would be using 0.12 or higher, so would accept the response
> based on the results of SmbSession.getNTLMResponse. This is one reason why I
> believe that the response computed by SmbSession.getPreNTLMResponse is
> ignored if the server is running NT LM 0.12 or higher. Just conjecture
> though.
> 
	How very astute! This is a mistake in the spec. Origianally I tried spaces and it didn't work.
	If I used nulls it worked. So the Pre NT LM 0.12 hash is not ignored and it must be 0's or it
	will not work. This was corrected in the latest SNIA version.

	Thanks for the patch!

	Mike