Hoje, qualquer organização possui um diretório LDAP preenchido com os usuários desta organização. Se você olhar atentamente, encontrará um ou mais aplicativos que usam o mesmo diretório para "autenticação". E as aspas não são acidentais aqui, porque LDAP é um protocolo de acesso a diretórios desenvolvido para leitura, gravação e pesquisa no serviço de diretório. Este não é um protocolo de autenticação. O termo “autenticação LDAP”, em vez disso, refere-se à parte do protocolo (operação de ligação), que determina quem você é e quais direitos de acesso você possui às informações do diretório.
Com o tempo, o LDAP se tornou um serviço de autenticação de fato. Serviços LDAP generalizados e acessíveis, como o Active Directory, tornaram-se um petisco para desenvolvedores de software que desejam integrar a autenticação em seus produtos. As bibliotecas cliente LDAP estão disponíveis para praticamente qualquer estrutura e a integração é relativamente fácil de implementar.
Mas, apesar do uso do LDAP poder ajudar a resolver o problema de implementar a autenticação do usuário em vários aplicativos da empresa, ele cria muitos problemas. Diferentemente dos protocolos de autenticação especialmente projetados, o uso do LDAP causa várias vulnerabilidades de segurança da informação.
Para entender o que são essas vulnerabilidades, primeiro você precisa entender como a autenticação LDAP funciona.
Como funciona a autenticação LDAP
Imagine a seguinte situação (está longe da realidade, mas transmite a essência perfeitamente).
Suponha que eu faça um pedido em uma loja online para que seja entregue em minha casa na minha ausência. O correio chega e deixa um bilhete embaixo da porta com o texto "Sinto muito, mas não o encontramos" e me pede para pegar o pedido no ponto de coleta mais próximo, em um horário conveniente. No ponto de coleta, o funcionário pede meu nome, endereço e pede as chaves da casa para confirmar minha identidade. Então o oficial do serviço de entrega chega à minha casa e abre a porta com a minha chave. Ele entra para garantir que eu moro lá, por exemplo, de fotografias na parede ou pelo nome do destinatário na correspondência. Depois disso, o funcionário retorna ao ponto de emissão e me informa que confirmou com sucesso minha identidade e que posso receber meu pacote! Viva!
Além de problemas com a logística, essa situação está cheia de outros problemas. E se um revisor inescrupuloso fizesse uma cópia da minha chave? Ou ele deixou a chave por um longo tempo sem vigilância e mais alguém? E se o testador foi atacado e minha chave foi retirada? Quando dou a chave do meu apartamento a um estranho, não posso ter certeza da decência dele e da minha segurança.
Felizmente, no mundo real, temos documentos de identificação, por exemplo, uma carteira de motorista ou passaporte, emitidos por agências governamentais, e sua autenticidade não está em dúvida. Posso fornecer esses documentos ao correio para minha própria identificação sem entregar as chaves.
No mundo LDAP, ainda precisamos passar nossas chaves para abrir a porta em nosso nome. Transferimos nossa senha para terceiros, e ele está tentando penetrar no servidor LDAP com ela. Se ele conseguir obter acesso, não podemos ter certeza de que nossas credenciais não sejam comprometidas. Nesse caso, o invasor terá não apenas a capacidade de desbloquear a porta LDAP, mas também o acesso a qualquer aplicativo que use as mesmas credenciais.
Felizmente, em um mundo mais completo de autenticação, também temos passaportes e carteiras de motorista! Protocolos de autenticação como Kerberos, SAML e OpenID Connect emitem tokens para terceiros. Os tokens confirmam que você é quem afirma ser e não há necessidade de transferir suas chaves para ninguém. Como o LDAP nunca foi projetado como um protocolo de autenticação, ele não possui os mecanismos apropriados.
Desvantagens do LDAP como um sistema de autenticação
Em 2007, Shumon Hack lançou um artigo de ficção científica (
Fraquezas do LDAP como um sistema central de autenticação ) no qual descreve três problemas específicos ao usar o LDAP como um sistema de autenticação.
1. O aplicativo provavelmente não é seguro o suficiente para manipular credenciais
O autor enfatiza que proteger um pequeno conjunto de servidores de autenticação contra ataques é muito mais fácil do que proteger um grande número de servidores de aplicativos.
Na maioria das vezes, os servidores de autenticação, em geral, estão sob a supervisão rigorosa de especialistas com experiência significativa no campo da segurança da informação.
Por outro lado, os servidores de aplicativos têm um nível de segurança completamente diferente e correm maior risco de comprometimento. Eles são menos seguros, trabalham com pilhas de software mais complexas e têm maior probabilidade de ter vulnerabilidades. E, mais frequentemente, são gerenciados por pessoas que não têm um conhecimento profundo de segurança. Construir o sistema de segurança certo é um processo complicado, no qual é muito fácil cometer um erro.
O problema é que, se um servidor de aplicativos estiver comprometido, todas as credenciais usadas por seus proprietários durante o ataque também serão comprometidas. Qualquer outro sistema que use o mesmo diretório LDAP para autenticação está em risco.
2. O servidor LDAP não pode proteger o mecanismo de autenticação usado para obter credenciais
Um servidor LDAP não pode garantir a segurança da transação. Embora um servidor LDAP, por exemplo, possa impor a ligação ao TLS para garantir que as credenciais não sejam transmitidas em texto não criptografado, o próprio servidor nunca assumiu nenhum papel na obtenção de credenciais do usuário. Existe o risco de o aplicativo receber uma senha por meio de um canal não seguro.
3. O usuário é forçado a compartilhar seu segredo de autenticação com terceiros
A senha do usuário ou o segredo de autenticação deve permanecer em
segredo . Deve ser conhecido apenas pelo usuário e pelo sistema de autenticação. Ao usar a autenticação LDAP, o usuário é forçado a compartilhar seu segredo com terceiros, para que possa usá-lo para interagir com o diretório LDAP em nome do usuário.
É importante mencionar que, ao usar protocolos de autenticação especialmente projetados, como o Kerberos, e mesmo a partir do NTLM anterior, o segredo do usuário nunca é transmitido pela rede. O dispositivo cliente e o servidor usam operações criptográficas para provar um ao outro que eles têm o mesmo segredo e nem trocam o próprio segredo.
Para os pontos de Shumon Hook, adicionarei uma descrição de várias nuances da autenticação LDAP, com base em minha própria experiência. Primeiro de tudo, o tópico se refere ao uso do Active Directory.
4. Muitos desenvolvedores não sabem o suficiente sobre os mecanismos LDAP para usá-lo corretamente
Uma das minhas postagens anteriores do
blog descreve como a ligação anônima e não autenticada permitiu enganar os desenvolvedores de aplicativos e fez os usuários não autorizados pularem. A capacidade de executar uma operação de ligação sem autenticação é uma das sutilezas do protocolo que nem os especialistas em LDAP mais experientes conhecem.
Os diretórios não são fáceis de organizar e são capazes de armazenar uma enorme quantidade de informações organizacionais e fornecem muitas maneiras personalizáveis de armazená-las. Vi muitos casos em que o desenvolvedor do aplicativo assumiu que havia uma certa classe ou atributo de objeto e, quando não foram detectados, o aplicativo travou. Para autenticação do usuário, o conhecimento da estrutura dos dados armazenados no diretório não deve ser necessário e aplicado. O protocolo de autenticação deve ser abstraído dos detalhes do repositório de objetos localizado em um nível inferior.
5. Os administradores de aplicativos geralmente não configuram clientes LDAP corretamente
Ao gerenciar o Active Directory em um grande ambiente distribuído, há uma nuance desagradável: é difícil determinar quais aplicativos específicos usam o Active Directory como o diretório LDAP e como exatamente os administradores de aplicativos configuraram o cliente LDAP.
A seguir, exemplos dos horrores da configuração incorreta.
- DN codificado em aplicativos ou usando DN em uma operação de ligação. Os problemas acontecem constantemente ao renomear ou mover objetos dentro de um diretório e tudo porque alguém em algum lugar codifica o DN. (Observação para aqueles que realizam operações simples de ligação com o Active Directory: não há necessidade de usar um DN. O Active Directory também fornece formatos DN alternativos que são mais confiáveis do que usar um formato tradicional).
- Para a operação de ligação, não é usada uma conta de serviço, mas uma conta pessoal do desenvolvedor ou administrador (imagine o que acontecerá quando o proprietário da conta deixar a empresa).
- Enviar senhas em texto não criptografado para a porta 389.
- Existem aplicativos em que a caixa de seleção "Validar certificado" não é necessária ao se conectar ao AD usando TLS (porta 636). Por que isso geralmente é aceitável? Como posso passar a senha para um serviço de terceiros sem estar convencido de sua autenticidade?
É fácil fazer o cliente LDAP funcionar. Mas apenas o fato de funcionar não significa que a configuração esteja correta.
6. A autenticação LDAP e os modernos serviços de autenticação são mutuamente exclusivos
Um aplicativo que usa LDAP para autenticação sempre terá que confiar em nomes de usuário e senhas. Tentar implementar tecnologias modernas, como autenticação multifatorial e logon único, é praticamente impossível (a menos que você implemente suas próprias tecnologias, o que por si só é uma má idéia). A Aliança FIDO está comprometida em tornar as senhas uma relíquia do passado, e todo aplicativo que usa autenticação LDAP será um obstáculo para uma política sem senha.
Quais são as opções?
Atualmente, os aplicativos da Web podem realmente ficar sem autenticação LDAP. Existem muitos protocolos excelentes de autenticação da Web, como SAML, WS-Federation e OpenID Connect, que não exigem credenciais de usuário para trabalhar com aplicativos de terceiros. Inúmeros produtos fornecem esses serviços, incluindo o Serviço de Federação do Active Directory (incorporado no Windows Server) ou serviços de terceiros, como o Microsoft Azure AD, Okta, Ping e outros. Se sua organização não possui um IdP federado, a primeira coisa a fazer é implementá-lo.
A principal coisa que você deve prestar atenção ao escolher um novo software é o suporte a protocolos de autenticação modernos. Mesmo que a empresa precise do aplicativo aqui e agora, não se apresse em escolher uma solução, especialmente se essa opção for limitada apenas a produtos com autenticação LDAP. Vale a pena tentar transmitir ao fornecedor selecionado a necessidade de refinar o produto usando protocolos de autenticação mais modernos. Talvez ele ouça e revise seu plano de desenvolvimento.
O número de aplicativos de desktop com um "cliente espesso" que suporta protocolos de autenticação modernos está crescendo, e essa é realmente uma tendência alegre. Esses aplicativos geralmente eram um reduto da autenticação LDAP. Um número crescente de SDKs, como o MSAL (Microsoft Authentication Library), facilita aos desenvolvedores adicionar suporte para serviços de autenticação modernos em seus aplicativos móveis e de desktop.
Por fim, vale a pena reconhecer que, na realidade de hoje, nem todos os aplicativos suportam protocolos de autenticação modernos, e talvez nunca o sejam. A implementação de uma proibição completa da autenticação LDAP provavelmente não é possível em nenhuma organização. No entanto, de nenhuma maneira a autenticação LDAP deve ser incentivada dentro da organização. O uso do LDAP deve ser considerado apenas na ausência de outras opções.