Um e-mail com a senha prova reversibilidade, não um esquema

Um serviço que envia por e-mail a senha atual de um usuário provou uma coisa: consegue obter esse segredo numa forma que consegue enviar. Não provou qual coluna, algoritmo ou biblioteca o produziu. A distinção importa porque o achado é real e a conclusão que as pessoas tiram dele costuma ser específica demais. A reversibilidade em algum ponto do caminho é o mecanismo; um formato de armazenamento suposto não é.

Mantenha as evidências nesse nível e o restante da revisão permanece preciso.

O que o reenvio do segredo antigo prova

Um verificador de mão única não consegue produzir a senha original, porque foi projetado para não ser invertível. Se o serviço consegue enviar a senha por e-mail, naquele momento ele guarda material do qual a senha pode ser recuperada, ou intercepta e armazena o texto simples antes do hash. Em qualquer caso, o caminho de recuperação é reversível, e isso é um achado de segurança genuíno. Não diz nada sobre se o mesmo banco de dados usa um hash caro para outras colunas.

Observe também o caso intermediário: um blob cifrado armazenado com uma chave mantida pela aplicação é reversível na prática, embora a palavra cifrado soe tranquilizadora num relatório.

Por que é um achado de projeto e não um mapa de armazenamento

O e-mail prova a recuperabilidade e não identifica o esquema exato. Pode ser texto simples, cifragem determinística, uma rotina de ofuscação de um fornecedor ou um armazenamento separado de credenciais usado apenas para recuperação. Partes diferentes de um produto costumam usar armazenamento diferente. Atribuir um algoritmo com base num único e-mail é o tipo de afirmação que desmorona numa reunião de acompanhamento.

O que você pode dizer é mais estreito e mais útil: este caminho consegue recuperar o segredo, então o produto não pode alegar que não existe credencial recuperável. Tudo além disso exige as evidências do operador.

Construa a redefinição em torno da autorização

Uma redefinição resolve outro problema: provar que o solicitante pode escolher uma nova senha. As orientações da OWASP sobre isso descrevem tokens ou códigos de uso único gerados com segurança e prazo de validade adequado, e tratam a etapa de solicitação como algo a proteger contra enumeração e inundação. Uma solicitação não autenticada não deve alterar a conta sozinha. Valide a autorização antes de aceitar a substituição e torne o token inutilizável após um uso bem-sucedido.

O canal de e-mail faz parte do modelo de segurança. Possuir um nome de conta não prova nada, e um fluxo de redefinição que revela se uma conta existe entrega a um atacante um diretório com o qual trabalhar.

Invalide o que a senha protegia

Trocar uma senha não encerra automaticamente o acesso que ela concedia. Sessões VPN ativas, dispositivos memorizados e tokens emitidos pelo servidor podem ter cada um seu próprio comportamento de invalidação. Decida deliberadamente quais deles devem terminar e verifique que a implementação faz isso, porque um usuário que supõe que uma redefinição o desconectou de todos os lugares costuma estar errado. Registre essa decisão junto com o fluxo.

Para os operadores: documente qual componente verifica a solicitação, qual altera a credencial e como as sessões relacionadas são tratadas. Para os usuários: proteja o canal de recuperação legítimo e trate qualquer mensagem que devolva uma senha como suspeita.

A avaliação precisa é curta: o que a mensagem demonstra, o que permanece desconhecido e se a recuperação substitui o acesso por um processo controlado.