[jcifs] Passwords longer than 14 characters [PATCH]

[Zalewski, Michael J (Michael)** CTR **]

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.

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.