Como eu implemento a Autenticação do Windows de maneira segura para uso em um ambiente de Internet?

Question

Eu estava lendo sobre Autenticação do Windows no IIS7

Eu sei por experiência que o Windows Authentication tecnicamente funciona bem na Internet usando o IIS - o que significa que o usuário é desafiado com 401 não autorizado e que a maioria dos navegadores (Chrome, FF, IE, Safari) solicita o domínio \ usuário e senha do windows e se a autenticação for bem-sucedida e, se autorizado, o usuário receber a página solicitada.

Mas então eu li isso:

Windows authentication is not appropriate for use in an Internet environment, because that environment does not require or encrypt user credentials.

O HTTPS pode ser usado para criptografia, mas estou buscando esclarecimentos sobre a outra parte.

O que significa "não requer credenciais do usuário"?

E com base nisso, a verdadeira questão: além de usar HTTPS para criptografia, como implementar a Autenticação do Windows de maneira segura para uso em um ambiente da Internet?

A afirmação da Microsoft parece infundada. Entendo que, ao usar o NTLM em vez do Kerberos, você perde a conexão direta com um provedor de identidade de terceiros confiável, mas isso não explica por que as credenciais não seriam necessárias se fossem implementadas corretamente. Buscando esse método. Obrigado.

    

Answer 1

O principal motivo pelo qual você não deve ter autenticação local e site voltado para a Internet é o fato de que, se o seu servidor web estiver sendo comprometido, todas as suas contas locais serão comprometidas. Com o Kerberos, você pode atualizar as senhas e ter um controle centralizado sobre a autenticação.

Agora a autenticação do kerberos pode usar os keytabs do SPN e você tem diferentes tipos de link de enquanto o NTLM usa apenas parcialmente a criptografia link . A menos que o NTLMSPP seja totalmente suportado e atualizado em seu sistema operacional, você estaria enviando credenciais em texto simples link e link . Atualmente, o NTLM não está sendo estendido e não é o protocolo de escolha link .

Como você pode ver, de acordo com a documentação da MS, o nome de usuário está em texto simples e a senha está em hash. Contra ataques NTLM "fáceis" são possíveis - passe o hash, ou prevendo o número aleatório gerado na sessão, então obtendo a senha fora dele. Além disso, o NTLM suporta criptografia 56 e 128, portanto, é mais baixo do que qualquer método recente.

Não há como implementar a autenticação local com segurança para um serviço voltado para a web. Por favor, deixe-me saber se isso faz sentido.

    

Answer 2

most of em don't use https either (even over internet) because they are too cheap to pay for certificates .

Configurar o site para exigir que o Https forneça uma medida razoável de segurança. Se você está procurando por outra coisa, porque eles não querem usar / pagar por certificados, você está desperdiçando o tempo de todos. Implementar o Windows Auth pela Internet sem exigir SSL seria irresponsável, porque o mecanismo integrado de autenticação do Windows pode não funcionar por vários motivos. Quando isso ocorre, eles são desafiados a inserir credenciais, que seriam transmitidas pela rede em texto simples, se o SSL não fosse necessário.

E nem sequer consideramos se os dados precisam ser criptografados.

Além disso, o NTLM e o Kerberos enviam a carga útil do cabeçalho de autorização http a cada pacote e esse cabeçalho inclui as credenciais hashed / munged. O Kerberos seria mais seguro que o NTLM, mas ambos poderiam ser suscetíveis a um ataque de repetição do MITM se o SSL não fosse usado.

Na minha experiência, pode ser difícil fazer com que o Windows Auth funcione de forma confiável mesmo em redes internas, e solicitar credenciais em conexões http não criptografadas quando não funcionar é uma falha que não pode ser ignorada. Há uma variedade de cenários em que pode não funcionar, inclusive o cabeçalho token / auth é muito grande devido a associações de grupo e / ou configurações insuficientes do IIS ou as credenciais do Windows estão fora de sincronia entre o cliente e o domínio do Active Directory. O problema de tamanho de token muito grande só ocorre com o Kerberos, porque as associações de grupo são armazenadas no PAC do Kerberos.