Implicações de permitir que clientes Windows usem NTLMv1?

Question

Eu tenho um aplicativo da Web que gostaria de autenticar para usar o NTLM de passagem para o SSO. Há um problema, no entanto, em que NTLMv2 aparentemente não funcionará neste cenário (sem o aplicativo armazenar um hash de senha idêntica).

Eu habilitei o NTLMv1 em uma máquina cliente (Vista) usando sua política de grupo local: Computador- > Configurações do Windows- > Configurações de segurança- > Segurança da rede: nível de autenticação do LAN Manager. Eu mudei para Enviar LM & NTLM - use segurança de sessão NTLMv2 se negociado.

Isso funcionou e consigo fazer login no aplicativo da Web usando o NTLM. Agora, esse aplicativo seria usado por todas as máquinas do meu cliente ... por isso, estou me perguntando quais são os riscos de segurança se eu fosse empurrar essa política para todos eles (não para o próprio controlador de domínio)?

    

Answer 1

É uma prática muito ruim, meio que permitir que o WEP proteja seu WiFi porque você tem um computador Windows 98 que não funciona com o WPA2. É 2009, o Kerberos funciona se você realmente precisa de SSO.

Também considero a autenticação integrada para sites uma prática ruim em geral, já que isso costuma levar a problemas excêntricos quando os usuários têm várias contas (utilizamos contas de usuário / administrador separadas), exige que você se concentre nas zonas de confiança do IE e requer que você use o IE ou mexa nas configurações do Firefox.

Dado o trembo que o IE tem sido e continua a ser desde 2002 ou sempre que o IE6 foi lançado, (ou seja, O patch do ActiveX fora da banda ) você realmente quer se comprometer com a plataforma?

    

Answer 2

O NTLM foi substituído pelo NTLMv2 no NT4.0 SP4. Isso é mais de uma década atrás. O NTLM é mais difícil que o LM para quebrar senhas, e o NTLMv2 é muito mais difícil. Existe uma razão para o Vista usar como padrão apenas o NTLMv2. As tabelas do arco-íris foram compiladas para o espaço completo de senha da LM e, por último, ouvi que o trabalho estava em andamento para fazer o mesmo com o espaço do NTLM. O NTLMv2 ainda não foi concluído.

Sim, há maiores riscos de segurança ao fazer isso. Se eles são ou não importantes para você, é sua própria avaliação de risco.

    

Answer 3

Como Adam e sysadmin afirmaram, essa é uma idéia muito ruim do ponto de vista da segurança (sem mencionar a perspectiva legada, pois foi substituída nos NT 4 dias e o NTLMv1 poderia ser removido de futuras versões do Windows). Que tal usar o Kerberos para autenticação / SSO? É mais seguro do que o NTLM v2, funciona em double-hop e terão suporte (dentro e fora da Microsoft) para o futuro previsível.

    

Answer 4

Se você tem alguma coisa sensível, eu não faria isso.

Se um hacker farejasse seu tráfego NTLMv1 SMB, eles poderiam usar algo como Cain & Abel com Rainbow Tables ( HalfLMChall pode ser mais rápido) ou RainbowCrack para quebrar a senha. Se a senha tiver sete caracteres ou menos, isso pode ser feito em um dia.

O NTLMv2 cria o hash usando outras variáveis em tempo real, e também usa espaço de senha de 128 bits com MD5 (não criptografa DES de 64 bits), então demora muito mais para crackar (mais em cracking NTLMv2 aqui ).

O NTLMv1 também armazena senhas localmente em hashes que podem ser usados para autenticar sem precisar saber a senha original . Então, se alguém pode possuir uma máquina local como administrador local, eles podem extrair hashes de um administrador de domínio ou usuário de domínio e obter as informações que podem obter do servidor sem sequer saber sua senha (mais sobre isso aqui ).

Se você realmente quisesse seguir a rota NTLMv1, certificaria-se de que todas as senhas tenham mais de 14 caracteres e incluam caracteres especiais.

    

Answer 5

Sim, um problema com o NTLMv1 é que ele usa o DES, que hoje em dia é considerado fraco sendo apenas de 56 bits. DES cracking ainda é difícil neste momento, no entanto. No entanto, há outra fraqueza. No NTLMv1, os hashes do LM / NT são transformados em três chaves DES diferentes e, em seguida, são usados para criptografar um desafio. Como os hashes são de 128 bits e DES é de apenas 56 bits, a terceira chave é de apenas 16 bits, com o restante preenchido com zeros, facilitando a quebra, revelando dois bytes de hashes NT e LM. O NTLMv2 corrigiu isso usando o HMAC-MD5. O MS-CHAPv1 também teve a mesma falha, e apesar do fato de que ele veio ao mesmo tempo que o NTLMv2, o MS-CHAPv2 não corrigiu isso. Eu me pergunto por que.

Editar: Agora, o CloudCracker tem um serviço de forçamento brusco de DES que aproveita esse problema no MS-CHAPv2.