EAP-MSCHAPv2
siglaSignifica: Microsoft Challenge Handshake Authentication Protocol version 2 (RFC 2759), carried inside EAP
O CHAP versão 2 da Microsoft, da RFC 2759, um desafio-resposta que prova uma senha sem enviá-la e acrescenta autenticação mútua, carregado dentro do EAP e, na prática, dentro do túnel do PEAP ou do EAP-TTLS.
A RFC 2759 (Zorn, da Microsoft, janeiro de 2000, Informational) especifica o MS-CHAP-V2. Seu avanço sobre a primeira versão é a autenticação mútua, obtida ao pegar carona de um desafio do par no pacote Response e de uma resposta do autenticador no pacote Success: o cliente responde ao desafio do servidor e envia seu próprio Peer-Challenge de 16 octetos; o NT-Response de 24 octetos é calculado a partir dos desafios e de um hash MD4 da senha usando DES; o servidor então prova que também conhecia a senha. O método exige que o servidor tenha o hash NT da senha, e é por isso que ele serve ao Active Directory e não serve a diretórios que guardam senhas em outras formas. Sozinha, pelo ar, a troca pode ser capturada e atacada offline, e a RFC já recomenda que o autenticador limite o número de tentativas de senha; embrulhada como método EAP dentro do PEAP (PEAP-MSCHAPv2) ou do EAP-TTLS, o túnel esconde a troca de quem escuta, que é a única configuração em que ela deveria aparecer numa rede hoje. O túnel não protege nada se o cliente não valida o certificado do servidor.
O MS-CHAP-V2 é o desafio-resposta no fundo da maior parte do Wi-Fi corporativo baseado em senha, e ele é anterior ao Wi-Fi: a RFC 2759, publicada em janeiro de 2000 por Glen Zorn, da Microsoft, como documento Informational, o especifica como protocolo de autenticação PPP, a segunda extensão do CHAP pela Microsoft, para clientes discados e de VPN. A RFC descreve a melhoria sobre a versão 1 como autenticação mútua, obtida ao pegar carona de um desafio do par no pacote Response e de uma resposta do autenticador no pacote Success. O servidor envia um desafio; o pacote Response do cliente carrega um Peer-Challenge próprio de 16 octetos e um NT-Response de 24 octetos derivado dos dois desafios e de um hash MD4 da senha do usuário, com o DES como cifra; no sucesso, o servidor devolve uma resposta de autenticador que prova que ele também conhecia a senha. Nenhum dos lados envia a senha, e o cliente fica sabendo se o servidor era legítimo, o que o CHAP sozinho não dizia.
A dependência do hash NT definiu onde o protocolo pode ser usado. Como o servidor precisa calcular a mesma função da senha que o cliente calculou, ele tem de guardar a senha na forma MD4 em que o Windows a guarda, ou a senha em claro; um diretório que guarda hashes salgados de outro tipo não consegue verificar MS-CHAP-V2. É por isso que o método combina naturalmente com o Active Directory, por isso servidores RADIUS que atendem um domínio o falam com fluência e por isso sites com um diretório LDAP de outra linhagem são encaminhados ao EAP-TTLS com PAP dentro do túnel.
Como método EAP, o MS-CHAP-V2 viaja em pacotes Request e Response com o nome EAP-MSCHAPv2; seu lugar correto é dentro de um túnel. A troca de desafio-resposta, capturada do ar, pode ser atacada offline contra a senha, e a criptografia da resposta é DES sobre um projeto dos anos 1990; a própria RFC 2759 recomenda que o autenticador limite o número de tentativas de senha contra adivinhação online, e a exposição offline só é tratada escondendo a troca. O draft expirado do PEAP descreve os métodos EAP internos que ele protege, e a RFC 5281 lista o MS-CHAP-V2 entre os métodos legados que o EAP-TTLS pode carregar; PEAP com EAP-MSCHAPv2 dentro virou a configuração padrão de Wi-Fi corporativo em redes Windows porque juntou um método que o domínio sabia verificar a um túnel que o ar não sabia ler.
A segurança desse arranjo é, portanto, a do túnel, e a segurança do túnel é a validação de certificado pelo cliente. Um atacante que convença um suplicante a completar um túnel TLS com um ponto de acesso impostor recebe o desafio-resposta MSCHAPv2 dentro dele e pode atacá-lo offline, o que transforma uma rede sem fio num coletor de senhas; a única defesa é um suplicante configurado para confiar num certificado de servidor nomeado e em nada mais. Engenheiros que perguntam por que a equipe de segurança quer certificados nos clientes, a resposta do EAP-TLS, podem apontar para este parágrafo: com EAP-TLS não há troca de senha a coletar. Onde as senhas permanecem, como permanecem na maioria das redes, EAP-MSCHAPv2 dentro do PEAP com validação imposta em todo cliente é a configuração, e o limite de tentativas no servidor é o segundo controle que a RFC já pedia.
Também conhecido como: ms-chap v2, mschapv2, ms-chapv2, ms-chap-v2, eap-mschap-v2