[jcifs] How long is a NtlmPasswordAuthentication object valid ?

Eric eglass1 at comcast.net
Thu Jul 17 10:34:31 EST 2003

> Here's the tricky part. The NPA password hases should be updated *in-place* if the
> client reauthenticates NTLM. So in theory the client could negotiate NTLM http
> authentication from which you get an NPA object and use that to access files, named
> pipes, etc. Then the transport to the target SMB server closes invalidating the NPA
> password hashes because the server challenge is now wrong. Now the client makes
> another request re-negotiating NTLM http authentication which updates the NPA
> password hashes *in-place* and you can go about your business with the *same*
> NtlmPasswordAuthenctication object.
> At one time this did work like that but I haven't tested this in a while. Can you confirm
> Eric?

Currently it creates a new NPA with the new hashes (rather than updating 
  the ansiHash/unicodeHash) and replaces the NPA in the session.  I 
don't remember it doing an in-place changeout, but it may have before I 
was involved; currently I don't think the NPA has a facility for 
changing out the hashes once the object is constructed.  I don't see any 
reason why it *couldn't*; from the HTTP side of things, we would just do 
something like:

if (auth == null) {
     auth = new NtlmPasswordAuthentication(domain, user,
             lmResponse, ntResponse);
} else {
     synchronized (auth) {

probably passing in the current auth (or null) to NtlmSsp, and returning 
either a new NPA or the current NPA with new hashes.  If there aren't 
any issues arising from the current scheme, I would be a bit wary of 
poking around; but on the other hand I'm always game for a bit of 


More information about the jcifs mailing list