Resumo

  • O HTML atual do WHOIS Crypt da AFRINIC declara um formulário POST para a mesma origem. O campo rotulado como senha é type="text" e tem o nome de envio plaintextpassword. Nenhuma senha foi digitada e o formulário não foi submetido nesta apuração.
  • O guia de membros diz que somente o hash deve ser compartilhado com a AFRINIC e que a senha em claro deve permanecer guardada pelo membro. O formulário introduz uma etapa de custódia que precisa ser explicada sem ser confundida com uma alegação de vazamento.

Uma senha pode estar protegida no caminho e ainda assim chegar a um destinatário. Também pode virar um bom hash e ter passado por componentes demais antes do cálculo. Essas duas frases não contradizem o HTTPS nem o BCRYPT. Elas apenas delimitam o trabalho que cada controle realmente faz.

A página de utilitários WHOIS da AFRINIC encaminha o membro a uma aplicação separada para produzir BCRYPT-PW. No HTML dessa aplicação, capturado em 14 de setembro de 2026, o formulário se identifica como myForm, usa method="POST" e aponta para a ação relativa ?lang=en#cli. O rótulo “Password” está ligado a um input type="text". Tanto o identificador quanto o nome enviado são plaintextpassword. O botão oferece “Generate hash”.

Não usamos o serviço. Nenhuma credencial real, senha sintética ou conta foi colocada no campo. Não apertamos o botão, não capturamos uma transação, não chamamos o processamento do servidor e não alteramos objetos WHOIS. A evidência é declarativa: mostra a instrução incorporada à página, não o resultado de uma submissão.

Essa distinção permite ler o formulário com rigor. O padrão HTML explica que os controles de um formulário recebem dados que podem ser enviados a um servidor para processamento. Sua seção voltada a desenvolvedores usa parâmetros em um corpo HTTP POST como exemplo comum desse fluxo. Como a ação da página é relativa, ela se resolve na origem whois-web.afrinic.net. Se o formulário funcionar conforme declarado, o navegador entrega ao endpoint da AFRINIC o valor de aplicação chamado plaintextpassword.

Isso é uma superfície de recebimento. Ainda não é evidência de armazenamento. O servidor pode manter o valor somente pelo tempo do cálculo, impedir que ele entre em qualquer registro e descartá-lo antes de responder. Também existem arquiteturas em que proxies, coletores de erro ou plataformas de observabilidade copiam corpos de requisição. Não examinamos código de servidor, configurações de proxy, logs, memória, rastreamentos nem registros de incidentes. Seria indevido escolher um desses cenários sem prova.

O HTTPS é a principal contraprova contra uma leitura alarmista. O TLS foi projetado para evitar espionagem e adulteração entre as pontas da conexão. Nada nas fontes mostra a senha trafegando de maneira legível para alguém no caminho. “Em claro”, aqui, descreve o valor anterior ao hash no nível da aplicação. Um valor pode estar cifrado durante o transporte e ser novamente legível na ponta que precisa processá-lo. Proteção do trajeto e minimização no receptor são camadas diferentes.

O tipo do campo trata de uma terceira camada. No HTML, type="password" representa informação sensível por meio de um controle que oculta a digitação. type="text" é um controle comum, sem essa semântica. A captura da AFRINIC usa o segundo. Não sabemos se alguém viu uma tela, e não há base para falar em exposição ou comprometimento. O fato só mostra que a página não solicita ao navegador o comportamento padrão de mascaramento para senhas.

Trocar o tipo do campo seria uma melhoria sensata, mas pequena. Protegeria a visualização casual e comunicaria melhor a finalidade ao navegador. Não mudaria o endereço do POST, não definiria a política de logs e não limitaria a vida do valor no servidor. Uma correção de interface não pode servir de recibo para a arquitetura inteira.

O contraste mais produtivo aparece no guia de referência dos membros da própria AFRINIC. Ao explicar o objeto maintainer, o texto recomenda gerar um hash BCRYPT da senha em claro. Em seguida, orienta que apenas o hash seja compartilhado com a AFRINIC e que os membros guardem a senha em claro com segurança. A alocação de responsabilidade parece direta: o membro conserva o segredo; o registro recebe o verificador.

Há uma interpretação que torna o guia compatível com o gerador remoto. “Compartilhar somente o hash” pode se referir ao valor final inserido no atributo auth: do banco WHOIS. O servidor do gerador receberia a senha apenas transitoriamente e nunca a colocaria no objeto. Essa leitura é possível e não deve ser descartada. Mesmo assim, ela exige que a palavra “compartilhar” tenha um escopo que a interface atual não esclarece.

Para outro leitor, a mesma frase pode prometer que a senha jamais deixa o dispositivo do membro. Nesse caso, um formulário remoto é uma arquitetura diferente da prometida. As fontes não mostram qual dessas promessas a AFRINIC pretende fazer. A conclusão correta não é declarar uma violação, mas pedir que o caminho intermediário seja nomeado.

A página também traz código para dentro do navegador. Ela carrega o Cloudflare Turnstile de challenges.cloudflare.com, além de jQuery, Mustache e um main.js por caminhos locais. A orientação da OWASP sobre JavaScript de terceiros trata esse código como uma fronteira de mudança e de dados sensíveis, porque o que executa no contexto do documento pode, em princípio, interagir com o documento. Essa é uma categoria de risco, não a descoberta de uma ação maliciosa.

O simples carregamento do Turnstile não prova que a Cloudflare leu, recebeu, guardou ou enviou plaintextpassword. Não inspecionamos a execução real do script. A formulação responsável é menor: há um fornecedor de código no mesmo documento de uma entrada sensível, portanto a capacidade e o isolamento devem fazer parte da explicação e dos testes.

O main.js local ligado pela página ajuda a remover outra suposição. A versão capturada não menciona myForm, plaintextpassword, BCRYPT ou um manipulador de geração Crypt. Seu código inicializa uma interface diferente, identificada por create-container, para carregar modelos, editar atributos e salvar objetos WHOIS. Ela usa seus próprios seletores e um fluxo próprio de senha do editor. Não é a transformação local do campo do gerador.

Essa ausência vale somente para o arquivo examinado. Não certifica jQuery, Mustache, Turnstile, extensões do navegador, respostas dinâmicas, versões futuras ou a rotina no servidor. Também não comprova que o POST sempre chega ao destino nem que é retido. Uma revisão estática reduz o espaço de afirmação; não deve ser usada para preenchê-lo com certeza fictícia.

A política de privacidade atual da AFRINIC é evidência positiva. Ela apresenta a AFRINIC como controladora, inclui os serviços WHOIS entre as superfícies de coleta, limita o acesso a pessoal designado, prevê garantias para terceiros e associa retenção a finalidades organizacionais ou exigências legais. Não seria correto dizer que o serviço opera sem compromissos de governança.

Mas essa política geral não é um mapa do campo Crypt. Ela não informa se o corpo do POST é excluído no proxy, se um erro captura argumentos, se o sistema de rastreamento amostra a entrada, se um pacote de suporte inclui o valor ou por quanto tempo a preimagem vive na memória. “Temos uma política de privacidade” e “este campo não deixa cópias” são alegações de níveis diferentes.

A recomendação de logging da OWASP oferece um teste concreto. Senhas de autenticação aparecem na lista de dados que normalmente não devem ser registrados diretamente; quando um evento precisa ser guardado, o conteúdo sensível deve ser removido, mascarado, saneado, hasheado ou cifrado. Não vimos um único log da AFRINIC. Por isso a pergunta deve ser formulada como condição verificável, não como acusação: o valor de plaintextpassword está ausente dos logs da aplicação e do proxy, dos rastreamentos, da análise, dos erros e das capturas de suporte?

O teste precisa incluir falhas. Um caminho de sucesso pode descartar o valor corretamente enquanto um tempo esgotado, uma validação Turnstile negada, uma entrada inválida ou uma exceção aciona um coletor genérico. Não há evidência de que isso aconteça na AFRINIC. É apenas a razão operacional para um recibo cobrir respostas normais e anormais.

Também não se deve confundir uma saída BCRYPT válida com uma prova de minimização. Comparar o formato do resultado testa parte do cálculo. Não mostra quais componentes viram a entrada, se ela entrou numa fila de repetição, se apareceu num painel de diagnóstico ou se um script podia lê-la. A matemática do verificador não registra a cadeia de custódia da preimagem.

Uma alternativa coerente é calcular no próprio navegador. Para ser confiável, ela precisaria de código revisável, dependências controladas, integridade verificável, isolamento de scripts de terceiros e demonstração de que nenhuma requisição de saída leva o valor original. Uma etiqueta “local” não substitui esses controles.

Outra alternativa coerente é manter o cálculo no servidor. A AFRINIC poderia avisar, antes da digitação, que o endpoint recebe por HTTPS uma senha nova e não reutilizada, usa-a apenas para produzir o hash, impede sua entrada em logs e rastreamentos, não retém a preimagem e restringe acesso de processadores. Geração remota não é, por definição, uma falha. Uma fronteira remota sem recibo é que deixa a confiança sem objeto.

O guia deve acompanhar a escolha. Se “somente o hash” descreve apenas o objeto WHOIS, essa limitação precisa ser explícita. Se descreve todo o processo, o POST remoto precisa mudar. Em qualquer arquitetura, a página deveria advertir que ninguém deve reutilizar ou redigitar uma senha vigente para experimentar o gerador. Esta pesquisa não o fez.

Fontes