Quebrando um Token de Redefinição de Senha Previsível

Quando você clica em "esqueci minha senha", o servidor gera um token de uso único, envia por e-mail um link contendo esse token e, depois, confia em quem apresentar esse token para redefinir a conta. O token é a única coisa que separa um atacante da conta, então sua propriedade mais importante é a imprevisibilidade: ele precisa ser um segredo longo e aleatório que o servidor armazenou e pode comparar, e nada mais.

O token deste desafio falha nesse teste. Parece um amontoado sem sentido de letras, mas o formato o entrega: é apenas base64, uma codificação reversível que qualquer um pode decodificar com um único botão, com a string legível invertida para adicionar uma fina camada de ofuscação. Codificação não é criptografia e não é um segredo: não existe chave, então a transformação funciona nos dois sentidos para qualquer pessoa. Um token que pode ser desfeito com dois cliques carrega entropia zero que um atacante também não possui.

O impacto é a tomada de conta. Se os tokens de redefinição são uma codificação reversível de dados da conta - um ID de usuário, um e-mail, um timestamp - um atacante que vê um link válido pode decodificá-lo, entender o padrão e forjar um token válido totalmente novo para outra conta sem nunca receber o e-mail dessa vítima. O link que "parece aleatório" é, na verdade, uma mensagem pública que qualquer um pode ler e reescrever.

• Assumir que um token é aleatório só porque parece ruído - uma string longa de letras maiúsculas e minúsculas é exatamente o que o base64 produz a partir de texto comum.
• Tratar base64 (ou hex, ou URL-encoding) como um controle de segurança. Essas são codificações reversíveis sem chave; elas não escondem nada de quem as reconhece.
• Adicionar "ofuscação", como inverter a string ou empilhar codificadores, e acreditar que isso gera proteção real. Obscuridade não é entropia - alguns cliques a mais não detêm um atacante.
• Derivar o token de dados previsíveis da conta (e-mail, ID sequencial, timestamp). Se as entradas são adivinháveis, o token é forjável.

Um token de redefinição precisa ser impossível de adivinhar para quem ainda não o possui, o que significa aleatoriedade real, e não uma transformação de dados conhecidos. Gere-o a partir de uma fonte aleatória criptograficamente segura, com tamanho suficiente para tornar o brute force inviável, armazene-o no servidor (idealmente como um hash, da mesma forma que se armazenam senhas) e, na redefinição, busque o valor e compare-o com o que foi armazenado. O token não deve revelar nada sobre a conta e nunca deve poder ser reconstruído a partir dos dados dela.

• Gere pelo menos 128 bits de entropia a partir de um CSPRNG (por exemplo, um valor aleatório de 32 bytes), nunca um contador, timestamp ou campo de usuário codificado.
• Armazene um hash do token, não o token em si, para que um vazamento do banco de dados não distribua links de redefinição ativos.
• Expire os tokens rapidamente (minutos, não dias) e invalide-os imediatamente após um único uso bem-sucedido.
• Limite a taxa de requisições de redefinição e nunca revele se um endereço de e-mail existe.