RFC 3112: senha correspondente não era autenticação

Resumo

A RFC 3112 dividiu o valor derivado em scheme, informação do scheme e valor de autenticação. A regra podia responder TRUE, FALSE ou Undefined, mas descrevia uma comparação, não uma associação LDAP autenticada.
O texto exigiu Bind para autenticar. Como o atributo aceitava vários valores, quem ganhasse permissão de escrita podia adicionar uma segunda senha válida sem tirar do usuário sua senha conhecida.

Um resultado verdadeiro antes do login

Um client envia uma senha para uma matching rule. O server encontra um valor, lê o scheme e o salt, calcula o resultado e responde verdadeiro. O segredo conferiu. Mesmo assim, o client ainda não se autenticou no diretório.

Essa separação é o centro histórico da RFC 3112, publicada como Informational em maio de 2001. “LDAP Authentication Password Schema” propôs guardar informação derivada da senha, em vez da senha que o uso contemporâneo de userPassword pressupunha. Definiu sintaxe, duas regras de matching, um atributo de capacidade na root DSE e uma classe auxiliar. Depois de facilitar o teste, restringiu sua interpretação: authPasswordMatch bem-sucedido por Compare ou Search não bastava para obter acesso. A autenticação ainda exigia Bind.

Os mecanismos respondiam perguntas distintas. Matching dizia se uma string correspondia a pelo menos um valor segundo seu método. Bind dizia se o server aceitava uma authentication identity para aquela associação LDAP. A política de acesso decidia então o que a authorization identity podia fazer. A aplicação fora do diretório continuava responsável pela ação de negócio.

Se o log resume tudo como “login bem-sucedido”, perde-se a cadeia. Match pode ocorrer sem Bind. Bind pode funcionar enquanto uma escrita é negada. Uma leitura autorizada no LDAP não prova que a operação visível ao usuário terminou.

O método acompanhava o valor

authPasswordSyntax carregava três componentes case-sensitive separados por cifrões: scheme, authInfo e authValue. O primeiro nomeava o mecanismo; o segundo geralmente levava o salt em base64; o terceiro levava o material derivado.

Assim, um diretório podia manter mecanismos diferentes. A RFC definiu MD5 e SHA1; nomes privados deveriam começar por X- ou usar OID. supportedAuthPasswordSchemes, permitido somente na root DSE, anunciava os nomes que o server dizia suportar.

O anúncio não era prova de execução. Não informava qual scheme foi selecionado para uma autenticação, quem escreveu o valor, se o salt era único, se o canal estava protegido, quais valores foram testados nem se Bind teve sucesso. Capacidade não é trilha operacional.

A data também limita a leitura. Nos schemes MD5 e SHA-1 da RFC 3112, o digest cobria a concatenação de senha e salt; o salt precisava ter ao menos 64 bits, e a implementação devia aceitar até 128 bits. É uma definição de 2001, não orientação atual. A RFC 8018 explicita salt e iterações em criptografia baseada em senha; a RFC 9106 especifica Argon2, memory-hard, e prefere Argon2id para hashing e derivação. Os textos posteriores não alteram o documento antigo, mas mostram por que “hash seguro” não substitui o nome e os parâmetros exatos.

Igualdade, teste de senha e autenticação

authPasswordExactMatch comparava os componentes codificados. Se um valor tivesse o mesmo scheme, authInfo e authValue, a resposta era true; se nenhum tivesse, false; nos demais casos, undefined. Era igualdade de representações.

authPasswordMatch recebia uma senha por extensible-match filter e aplicava o scheme de cada valor. Uma correspondência tornava a resposta verdadeira; falha em todos os valores a tornava falsa; incapacidade de concluir produzia Undefined.

Nenhuma resposta identificava a pessoa diante do teclado. True não provava quem controlava o canal nem se o solicitante podia testar o atributo. False não provava que a entry era a correta ou que não existia outro credential store. Undefined não era senha errada: preservava a ausência de conclusão.

A exigência de Bind impedia que a comparação assumisse mais autoridade. A RFC 4511 descreveu depois o resultado de Bind na revisão do protocolo. A RFC 4513 separou authentication identity de authorization identity. Esta podia ser derivada da primeira ou, com mecanismo adequado, pedida separadamente se o server autorizasse a representação.

Nem Bind significava permissão universal. A autenticação dizia quem o server aceitava naquela associação; a autorização decidia o que aquela identidade podia fazer com aquele objeto; a aplicação decidia o resultado final.

Mais de um valor, mais de uma porta

authPassword podia conter vários valores. Nos schemes selecionados, o server deveria considerar todos os pertinentes, e um único match podia validar a senha. Isso servia a migrações e sobreposições planejadas, mas também transformava write access em capacidade de criar uma nova entrada.

A RFC apontou o ataque: alguém com escrita podia adicionar outro valor sem desabilitar a senha verdadeira do usuário. A vítima continuaria entrando normalmente, sem reset ou lockout visível, enquanto a porta adicional permanecia ativa.

O snapshot final da entry não reconstrói a autoria. Dois valores não contam quem adicionou cada um, qual política permitiu, o que deveria ser substituído ou quando a aceitação começou. É preciso guardar add, replace e delete; writer e authorization identity; fingerprint; scheme; parâmetros; replicação; e retirada.

A RFC 3062 já havia definido Password Modify. Sob regras do server, a operação podia identificar o alvo, aceitar ou gerar uma nova senha e escolher seu armazenamento. A RFC 3112 podia trabalhar com ela, mas o atributo isolado não era um sistema completo de ciclo de vida.

O server também podia combinar authPassword, userPassword e um store externo. Observar ou remover um valor não revelava necessariamente todos os caminhos de autenticação.

Valor derivado ainda era segredo

A RFC não tratou função de mão única como licença para publicar. Recomendou proteger os valores como senhas em claro: falha do algoritmo, erro de implementação ou ataque offline podiam transformar vazamento em acesso. Transferir sem confidencialidade era fortemente desaconselhado.

A assertion de authPasswordMatch também precisava de proteção. Ela transportava a tentativa de senha. Canal aberto podia revelá-la; comparação exposta demais podia virar oracle de guessing.

O custo computacional trazia risco de disponibilidade. Um scheme caro aumenta o trabalho do atacante, mas também permite consumir CPU do server. Rate limit, orçamento de concorrência, timeout e permissão para comparar pertencem ao significado operacional. O nome de um scheme não prova que esses controles existiam.

O contexto mudou; a separação ficou

A RFC 3112 contrastou sua proposta com userPassword no contexto das RFCs 2251, 2252 e 2256. Isso não deve virar regra eterna. A RFC 4519 esclareceu depois que valores de userPassword não precisavam ser clear text nem utilizáveis por Bind. Implementações criaram convenções próprias.

O status Informational também impede uma alegação de adoção. RFC Editor e IETF Datatracker provam publicação e histórico. RFC 2829 e RFC 4513 mostram o modelo de segurança; RFC 4511, RFC 4517 e RFC 4519 mostram a linhagem revisada. Nenhuma fonte prova que um diretório específico implantou authPassword.

O ensinamento durável é preservar as transições. Para dizer que alguém “entrou”, é preciso guardar a entry e seu histórico, scheme, salt e parâmetros; a autorização para Compare ou Search; canal; request e resposta true, false ou undefined; valores testados; Bind e seu mecanismo; authentication e authorization identities; operação seguinte; access control; e resultado da aplicação.

A senha podia conferir perfeitamente. A RFC 3112 sabia que essa verdade não podia falar em nome de Bind.

A senha conferiu. O usuário ainda não estava autenticado: RFC 3112

Por que isso importa

Resumo

Um resultado verdadeiro antes do login

O método acompanhava o valor

Igualdade, teste de senha e autenticação

Mais de um valor, mais de uma porta

Valor derivado ainda era segredo

O contexto mudou; a separação ficou

Fontes

Contexto aprofundado do perfil

Strategic Circle

Leadership Alliance

Briefing do Strategic Circle

Briefing da Leadership Alliance