[jcifs] authentication session concurrency
Michael B Allen
mba2000 at ioplex.com
Tue Oct 14 09:24:59 EST 2003
> There is (arguably) a replay hole in this design; since all
> over the SMB connection use the same challenge, a man-in-the-middle could
> sniff the LM/NTLM responses and use them to his nefarious advantage.
One feature that might be worth considering later is if the
jcifs.smb.client.ssnLimit is reached, rather than closing sessions or in
addition to closing sessions, a new SmbTransport is created (and thus new
challenge) to replace the current transport for that target in the
transports table. The truely paranoid could set this limit to 1 in which
case every session get's it's own transport. I'll keep it in mind when I
get around to cleaning up/rethinking NetBIOS and SmbTransport. This sort
of feature might have also assisted with Marco's "only authenticate from
the workstation they are registered to" problem (although I think NETLOGON
is still the "proper" solution for that one).
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not
yet been conceived.
More information about the jcifs