Never send the LM response on cached credentials

[Andrew Bartlett]

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

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060829/88a380c0/attachment.bin