Auditoria do armazenamento de senhas: hashing, salting e migração segura

O que uma auditoria de armazenamento de senhas verifica (e por que você deve se importar)

Um bom armazenamento de senhas significa algo simples: se alguém roubar sua base de usuários, ainda assim não consegue usar aquelas senhas.

Sua aplicação nunca deve guardar senhas em texto legível. Deve armazenar um hash unidirecional que seja lento para ser adivinhado, único por usuário, e configurado de forma que você possa atualizá‑lo ao longo do tempo.

Uma auditoria de armazenamento de senhas verifica toda a cadeia, não apenas a tela de login. Em código herdado (especialmente gerado rapidamente por ferramentas de IA), logins podem parecer funcionar enquanto o armazenamento é inseguro. Um protótipo pode hashear senhas com uma função rápida, reutilizar o mesmo salt ou acidentalmente logar segredos durante depuração. Nada disso quebra o caminho feliz, mas pode transformar um vazamento de dados em uma onda de invasões de conta.

Se atacantes obtêm hashes fracos, eles podem rodar ataques de adivinhação offline. Não precisam atingir seus servidores nem acionar limites de taxa. Eles simplesmente continuam tentando palpites nas próprias máquinas até encontrar correspondências. Quando quebram uma senha, muitas vezes tentam usá‑la em outros serviços porque pessoas reaproveitam senhas.

Um bom armazenamento de senhas normalmente inclui:

• Um algoritmo moderno e lento para hashing de senhas (não um hash de uso geral como MD5 ou SHA‑1).
• Um salt aleatório e único por senha, armazenado junto com o hash.
• Pepper opcional: um segredo separado guardado fora do banco.
• Versionamento claro para que você possa mudar configurações depois sem quebrar logins.
• Nenhuma exposição acidental (logs, eventos de analytics, mensagens de erro, backups).

A sequência mais segura é auditar primeiro, migrar depois. A auditoria identifica o que você tem hoje (algoritmo, configurações, onde o código vive, como resets funcionam), então você escolhe um plano de upgrade.

Um plano comum é “rehash no próximo login”: os usuários continuam entrando normalmente e, quando a senha for verificada com sucesso, você atualiza o hash armazenado para o novo padrão.

Sinais de alerta que você pode achar rapidamente em código herdado

Você não precisa reescrever tudo para encontrar os maiores riscos. Uma auditoria rápida geralmente começa com buscas simples que revelam se senhas estão sendo armazenadas ou tratadas de forma insegura.

O sinal mais urgente é qualquer coisa que sugira que senhas possam ser recuperadas. Se você vê senhas salvas diretamente em colunas do banco, logadas no console, enviadas para analytics ou “criptografadas” de forma reversível (como AES com chave armazenada), trate como incidente. Senhas devem ser armazenadas apenas como hashes unidirecionais.

Outro problema comum é o uso de hashes rápidos. Você pode ver MD5, SHA‑1 ou SHA‑256 aplicados diretamente na senha. Mesmo que “pareça hashed”, hashes rápidos são feitos para velocidade, o que os torna fáceis de quebrar em escala. Se o código diz hash(password) e nada mais, é um forte indício de que não está usando uma função de hashing de senha corretamente.

Checagens rápidas que pegam muitos dos piores problemas:

• Menções a md5, sha1, sha256(password) ou helpers chamados “encryptPassword”.
• Saídas de hash que têm sempre o mesmo comprimento e formato, sem sinal de um salt por usuário.
• Senhas ou tokens de reset aparecendo em logs, relatórios de erro ou dumps de banco.
• Segredos (chaves JWT, senhas de BD, PEPPER=...) hardcoded no repo ou em configs commitadas.
• Código de login que assume apenas um formato de hash e não tem caminho de upgrade.

Salting ausente ou quebrado é sutil, mas fácil de detectar quando você sabe onde olhar. Se dois usuários com a mesma senha têm o mesmo valor armazenado, o sistema provavelmente usa nada, um salt global ou um salt previsível. Uma configuração saudável produz resultados armazenados diferentes mesmo para senhas idênticas.

Exemplo prático: você herda uma app Node e encontra uma coluna users.password cheia de strings hex de 64 caracteres. O handler de login faz sha256(req.password) e compara com o banco. “Funciona”, mas é vulnerável, e não dá um caminho seguro para melhorar sem planejar múltiplos formatos de hash.

Por fim, verifique se o fluxo de login consegue lidar com mudança. Se o código não consegue verificar hashes legados e então rehashar com um método mais forte no próximo login bem‑sucedido, upgrades ficam arriscados e podem levar a lockouts.

Mapear onde senhas e fluxos de reset são tratados

Uma auditoria anda mais rápido quando você começa com um mapa simples: todo lugar onde uma senha ou token de reset é criado, enviado, processado ou armazenado. Em código herdado, as partes arriscadas muitas vezes não estão numa pasta “auth”. Elas estão espalhadas por formulários de UI, rotas de API, jobs em background e ferramentas admin.

Comece listando cada ponto de entrada onde uma senha pode entrar no sistema e confirme cada um no código e nas configs de produção. Lugares comuns incluem fluxos de signup, login (incluindo caminhos de fallback SSO), reset e recuperação de senha, ferramentas de admin/suporte e imports ou migrations (uploads CSV, sync com CRM, seed scripts).

Em seguida, localize onde dados relacionados a senha ficam no banco. Verifique colunas óbvias como password, password_hash e hashed_password, mas também tabelas legadas e cópias sombra (por exemplo, uma tabela antiga users_legacy ainda lida por um job em background). Se achar mais de um campo de hash de senha, anote qual é realmente usado no login.

Logging é outro vazamento comum. Busque no código e nas configs de monitoramento qualquer coisa que possa capturar valores sensíveis: logs de requisição, eventos de analytics, relatórios de erro e prints de depuração. Um modo realista de falha: um handler de falha de login loga o corpo da requisição inteiro “para troubleshooting”, enviando silenciosamente senhas em texto claro para logs.

Resets de senha merecem seu próprio mini‑mapa porque tokens são fáceis de manejar errado. Identifique como tokens são gerados (fonte de aleatoriedade), onde são armazenados (linha do banco, cache, payload do link por e‑mail) e como expiram. Verifique também se tokens são single‑use e o que acontece se um token for reproduzido após a senha ser alterada.

Finalmente, desenhe o boundary de serviço. Note cada componente que toca auth: cliente frontend, API gateway, serviço de auth, workers em background (email, SMS) e qualquer provedor terceiro de identidade. Em projetos gerados por IA, também é comum encontrar endpoints extras de auth deixados para trás durante iterações, então inclua rotas antigas e flags de features desabilitadas na varredura.

Verificar o algoritmo de hashing e suas configurações

Uma auditoria de armazenamento de senhas começa com uma pergunta direta: você está usando uma função de hashing para senhas ou um hash de uso geral?

Se vir MD5, SHA‑1, SHA‑256 ou qualquer coisa descrita como “encrypt password”, trate como um problema sério. Essas ferramentas não são feitas para desacelerar atacantes.

Prefira hashes dedicados a senhas como Argon2id, bcrypt ou scrypt. Eles foram criados para serem caros de quebrar, então hashes vazados ficam mais difíceis de virar senhas reais.

Como saber o que você tem a partir do hash armazenado

A maioria dos sistemas guarda o algoritmo e as configurações dentro da string do hash, então uma olhada rápida em um valor do banco pode dizer muito.

Padrões comuns:

• Argon2id frequentemente começa com $argon2id$ e inclui memória e iterações.
• bcrypt costuma começar com $2a$, $2b$ ou $2y$ e inclui um cost como 10 ou 12.
• scrypt pode mostrar $scrypt$ ou parâmetros como N, r e p dependendo da biblioteca.

Se você vir uma string hex de tamanho fixo (por exemplo, 32 ou 64 chars) sem separadores $, pode ser um hash geral ou um esquema customizado que precisa de revisão mais profunda.

Verifique as configurações, não apenas o nome

A escolha do algoritmo é só metade da história. Argon2id pode ser fraco se a memória estiver ínfima. bcrypt pode ser fraco se o cost for muito baixo.

Procure onde o fator de trabalho é definido e se você pode mudá‑lo sem redeploy. Setups saudáveis mantêm configurações de custo em config, usam o método verify da biblioteca (não uma comparação manual de strings) e fazem comparação em tempo constante.

Confirme também que o endpoint de login tem defesas básicas: rate limiting por conta e por IP, além de regras de bloqueio sensatas. Bloqueios curtos e temporários geralmente são mais seguros que permanentes.

Checar salting: unicidade, armazenamento e aleatoriedade

Uma auditoria deve confirmar uma regra: cada hash de senha deve ter seu próprio salt único e aleatório.

Se dois usuários escolherem a mesma senha, os valores armazenados ainda devem parecer diferentes. Se coincidirem, algo está errado.

Unicidade: um salt por senha, sem exceções

Salts impedem que atacantes usem tabelas pré‑computadas e tornam a quebra em massa muito mais difícil. Isso só funciona quando salts não são reutilizados.

Um problema comum em código herdado é um salt único hardcoded num arquivo de config ou um “salt padrão” reutilizado para todo mundo. Um cheque rápido é pegar uma amostra de hashes armazenados (20–50) e ver se compartilham um segmento de salt idêntico ou um prefixo repetido que sugira reutilização. Se encontrar repetição, trate como bug de segurança.

Armazenamento: embutido no hash vs coluna separada

Muitos formatos modernos armazenam o salt dentro da própria string do hash. Por exemplo, hashes bcrypt e Argon2 normalmente incluem algoritmo, parâmetros, o salt e o hash num único campo. Isso é normal.

Alguns sistemas armazenam o salt numa coluna separada ao lado do hash. Isso também pode ser aceitável, desde que seja realmente por usuário e não nulo ou com valor default compartilhado. O risco com colunas separadas é reutilização acidental via migrations, defaults do ORM ou seed scripts.

Checagens práticas que pegam a maioria dos problemas:

• Confirme que cada usuário tem um valor de salt diferente (ou um salt embutido diferente na string do hash).
• Confirme que salts são gerados durante set/reset de senha, não na inicialização da app.
• Verifique se o comprimento do salt bate com o esperado pelo algoritmo.
• Garanta que o código use uma fonte de aleatoriedade criptograficamente segura.
• Evite formatos customizados de salt que concatenem strings manualmente.

Aleatoriedade importa tanto quanto unicidade. Se o salt vem de fontes previsíveis (timestamps, usernames, IDs incrementais), atacantes podem adivinhar.

Um modo de falha realista em protótipos gerados por IA é um helper como salt = Math.random().toString(36) ou um SALT="abc" copiado em vários arquivos. Parece aleatório, mas não é seguro.

Se precisar mudar como salts são gerados ou armazenados, faça de um jeito que mantenha usuários existentes logando normalmente e então atualize os hashes com segurança no próximo login bem‑sucedido.

Decidir sobre pepper e como armazenar o segredo com segurança

Um pepper é um valor secreto adicionado à senha antes do hashing. Ao contrário do salt (único por usuário e armazenado com o hash), o pepper é compartilhado entre muitos usuários e deve ficar somente no servidor.

Peppering ajuda mais quando você está preocupado com vazamentos de banco e ataques offline. É especialmente útil em apps herdadas em que você não confia totalmente no que foi gerado ou quando segredos já podem ter sido expostos.

Peppering pode piorar a situação se você tratá‑lo como uma string de config normal. Se o pepper vazar (hardcoded no repo, impresso em logs, copiado para o app cliente), você ganha pouco e adiciona risco. Também pode provocar outage se um deploy remover ou trocar o pepper: de repente ninguém consegue logar.

Armazene o pepper como um segredo de verdade:

• Mantenha fora do banco e do controle de versão.
• Carregue de variáveis de ambiente ou de um secrets manager usado pela sua infra.
• Limite acesso às poucas pessoas e serviços que precisam dele.
• Nunca envie ao navegador ou app móvel.
• Evite logar qualquer coisa que possa revelá‑lo (nem mesmo valores parciais).

Planeje rotação antes de entrar em produção. Rotacionar um pepper é mais difícil que rotacionar uma API key porque afeta todas as verificações de senha.

A abordagem mais segura é suporte dual‑pepper por uma janela: aceite o pepper antigo e o novo e atualize usuários gradualmente. No login, verifique com o novo primeiro. Se falhar, verifique com o antigo. Se o antigo funcionar, rehash e salve usando o novo. Assim a rotação ocorre sem forçar resets.

Documente quem pode ver ou mudar o pepper, onde ele é definido em cada ambiente e qual é o plano de rollback se um deploy quebrar logins.

Passo a passo: migrar hashes com segurança no próximo login

Um plano seguro de “rehash no próximo login” permite aceitar senhas existentes e ao mesmo tempo melhorar o armazenamento sem forçar um reset em massa. É uma das correções de maior impacto porque reduz o risco rapidamente sem interromper usuários.

1) Detectar se o hash armazenado é legado ou moderno

Faça o valor no banco ser auto‑descritivo. A maioria dos formatos já é. Por exemplo, bcrypt inicia com $2a$ ou $2b$, e Argon2 com $argon2id$.

Se o sistema legado usava algo customizado (como sha1(salt+password)), adicione uma coluna explícita hash_version para poder saber o que verificar.

2) Verificar usando o método legado apenas quando necessário

No login, cheque o formato/versão armazenada primeiro. Se for moderno, verifique normalmente. Se for legado, rode apenas o verificador legado para aquele usuário.

Fique atento a “double hashing” (hashing da senha recebida antes de passar ao verificador). Garanta que o verificador receba a string de senha crua exatamente uma vez.

3) Rehash com o novo algoritmo e sobrescreva em caso de sucesso

Se a verificação legado for bem‑sucedida, imediatamente rehash com a nova escolha e configurações atuais (por exemplo, Argon2id ou bcrypt com cost mais forte) e grave no formato moderno.

Mantenha a atualização atômica e vinculada ao ID do usuário para evitar races. Uma abordagem simples é “verificar primeiro, então atualizar hash e hash_version em uma única escrita”.

if verify(password, stored_hash, version) == true:
  new_hash = hash_new(password)
  update users set password_hash = new_hash, hash_version = "v2" where id = user_id
  allow_login()
else:
  deny_login()

Exemplo concreto: você herda um protótipo que usava SHA‑1 sem salt mais um segredo global. Você mantém esse verificador apenas para validar contas antigas. Após o primeiro login bem‑sucedido, a linha é atualizada para Argon2id e logins futuros nunca mais tocam SHA‑1.

4) Adicionar observabilidade sem vazar segredos

Acompanhe progresso e problemas, mas nunca logue senhas ou hashes completos. Registre apenas contadores e resultados seguros, como logins legados bem‑sucedidos (rehash ocorreu), logins legados falharam, logins modernos bem‑sucedidos/falhos, número de usuários ainda em formato legado e erros de rehash (write falhou, versão diferente).

Erros comuns de migração que travam usuários

Uma atualização de hash deve ser invisível para usuários. A maioria dos lockouts acontece quando a migração muda comportamento, não segurança.

Um grande erro é forçar reset de senha sem plano. Se você invalidar todos os hashes existentes, pessoas que não têm mais acesso ao e‑mail antigo (ou que usam SSO às vezes) ficam presas. Mesmo se tiver que forçar resets após um incidente, ainda precisa de caminhos de fallback, comunicação clara e suporte para casos como emails não verificados.

Outro erro comum é atualizar hashes em tentativas de login falhas. Com senha errada, você não conhece o plaintext correto, então não pode rehashar. Pior, algum código sobrescreve o hash armazenado com lixo derivado da entrada errada, bloqueando o usuário mesmo que depois digite a senha correta.

Mudanças de normalização também podem quebrar logins silenciosamente. Diferenças pequenas como trim de espaços, regras de maiúsculas/minúsculas ou tratamento de Unicode podem fazer a mesma senha gerar hash diferente. Exemplo realista: um app herdado removia espaços finais no signup mas não no login. Após uma reescrita, ambos passaram a remover e alguns usuários que usavam espaço final intencionalmente não conseguiram entrar.

Finalmente, cuide de logins concorrentes e condições de corrida durante rehash. Se dois dispositivos logarem ao mesmo tempo, ambos podem tentar atualizar o hash. Se a atualização não for atômica, uma requisição pode sobrescrever a outra ou falhar deixando a conta inconsistente.

Checklist curto para evitar lockouts:

• Rehash apenas após uma verificação de senha bem‑sucedida.
• Mantenha regras de normalização exatamente iguais durante a migração.
• Armazene o pepper só no servidor, nunca no cliente.
• Faça a atualização do hash atômica (uma escrita, protegida pelo hash atual esperado).
• Logue e alerte sobre falhas de migração sem bloquear logins válidos.

Checagens rápidas antes de deployar as mudanças

Antes de liberar qualquer trabalho relacionado a senhas, faça uma passagem prática que pegue os erros que os usuários sentem imediatamente: logins falhando, resets quebrados e vazamentos acidentais em logs.

Teste o fluxo de login e rehash com entradas reais e “sujas”. Não confie em uma conta feliz. Tente senhas muito longas (200+ caracteres), Unicode, contas antigas que não fazem login há meses e usuários criados por caminhos diferentes (signup, import admin, OAuth seguido de set de senha). Confirme que mensagens de “senha errada” são genéricas e consistentes e não revelam se uma conta existe.

Resets de senha merecem checagem própria porque código herdado costuma armazenar tokens em texto simples. Trate tokens de reset como senhas: armazene só um hash do token e compare hash do token enviado pelo usuário. Verifique expiração, uso único e que tokens não possam ser reaproveitados. Um cenário simples: solicite dois resets em sequência, use o primeiro token e confirme que o segundo é rejeitado.

Não libere sem um plano de rollback. Faça um backup fresco e documente exatamente como reverter se logins dispararem ou tickets de suporte inundarem. Confirme também que a atualização “rehash on next login” se comporta de forma segura se falhar no meio (ex.: a senha verifica mas a escrita no banco falha). Usuários devem conseguir logar na próxima tentativa.

Por fim, rode uma verificação básica de abuso. Adicione limites de taxa em endpoints de login e reset, e garanta que padrões suspeitos sejam sinalizados (muitas tentativas, muitos resets, falhas repetidas de um mesmo IP). Reveja logs e tracking de erro — eles nunca devem incluir senhas em texto, tokens de reset ou headers de autorização completos, nem mesmo em modo debug.

Próximos passos: fazer a auditoria e endurecer código herdado gerado por IA

Se você herdou um app gerado por IA, trate autenticação como a parte que pode te ferir mais rápido. Uma auditoria de armazenamento de senhas é geralmente a maneira mais rápida de encontrar problemas que levam a invasões de conta.

Um padrão comum é um protótipo com auth remendado: configurações de hashing fracas, segredos hardcoded e um fluxo de reset que pode ser abusado. A app funciona no demo, mas não é segura em produção.

Priorize em ordem sensata. Primeiro, remova segredos expostos, bloqueie qualquer lógica de fallback de login insegura e corrija caminhos óbvios de injeção em endpoints relacionados a auth. Depois migre usuários gradualmente para não forçar resets em massa.

Se quiser um especialista para revisar e consertar rápido, ajuda preparar acesso ao repositório (ou um export limpo), a branch que planeja deployar, uma forma de rodar a app localmente (env vars, DB de teste), algumas contas de teste (incluindo uma conta legada se tiver hashes antigos) e notas sobre onde os segredos vivem hoje (config de hosting, env files, CI).

Se você está lidando com um codebase gerado por IA e não tem certeza do que realmente está armazenado, FixMyMess (fixmymess.ai) foca em diagnosticar e reparar apps construídos por IA, incluindo lógica de autenticação, manejo de segredos e migrações seguras “rehash on next login”. Eles oferecem uma auditoria gratuita de código para identificar problemas antes de você commitar, com a maioria dos projetos finalizados em 48–72 horas.

Um estado “pronto” claro mantém o trabalho focado:

• Novas senhas sempre usam o hash e as configurações aprovadas.
• Logins bem‑sucedidos atualizam hashes legados automaticamente.
• Fluxos de reset e mudança de senha são testados e rate‑limited.
• Nada de senhas em texto, nenhuma criptografia reversível, nenhum segredo exposto.
• Contagem de hashes legados tende a zero conforme usuários ativos fazem login.

Se você consegue nomear o método de hashing atual mas não suas configurações, ou não sabe quantos usuários ainda estão em hashes legados, isso é sinal para pausar e auditar antes do próximo release.