Never send the LM response on cached credentials
abartlet at samba.org
Tue Aug 29 01:48:32 GMT 2006
On Sun, 2006-08-20 at 12:02 +1000, Andrew Bartlett wrote:
> On Sat, 2006-08-19 at 14:50 -0700, Jeremy Allison wrote:
> > On Sun, Aug 20, 2006 at 07:49:25AM +1000, Andrew Bartlett wrote:
> > >
> > > We never need the LM hash. Indeed, we could perfectly safely modify the
> > > NTLMSSP code to never send the LM response.
> > There are some places in the code where the lm hash is used.
> My point is that in 2006, I do not think there are any situations where
> a cached credential can be used, but an NT password is not available.
> A cached credential implies that we are talking to a DC, and any DC
> these days has an NT password, so sending the LM password only exposes
> weaknesses in that hash. This is also what Firefox *always* does (it
> never sends an LM response from it's builtin NTLMSSP code).
> In protocol terms, we typically place the NT response in that position
> in the session setup or NTLMSSP packets.
> For a stronger solution, we could avoid various attacks on the user's
> password by insisting that *either* NTLM2 is used, or NTLMv2 is used.
> We could even make NTLMv2 the default: it would make us much more
> secure (and not be a loss in functionality, as we are adding additional
> functionality at this point).
Have we progressed anywhere on this? I'm concerned that if we allow
userspace applications to request a user's LM response, then it becomes
very easy to crack a user's logon password.
Likewise if we allow a userspace application to ask for an NT response,
without NTLM2 or NTLMv2 negotiated.
Both of these attacks can occur locally, or by a malicous server
remotely. By requiring NTLM2 or NTLMv2 we at put a locally controlled
random factor into the equation, preventing simple lookup-based attacks.
(I think we should never send the LM or plain NTLM response over the
network, but that's a battle for another day).
This becomes particularly easy to enforce if a design such as the one
used in the Samba4 credentials code is taken on board. (I created a
callback function to abstract this, specifically to create a single
choke point for these 'security level' questions).
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060829/88a380c0/attachment.bin
More information about the samba-technical