Guardar um hash em vez da senha é correto apenas se a função for apropriada. SHA-256 é one-way, mas foi otimizado para velocidade. Após roubar a base, o atacante não precisa inverter o digest. Ele testa senhas prováveis, calcula hashes e compara. Uma função rápida permite bilhões de tentativas. Password hashing torna cada guess caro.
O ataque acontece offline
Rate limits, CAPTCHA e MFA protegem o login online. Uma tabela roubada remove essas barreiras. O atacante usa hardware próprio sem enviar requests para a aplicação.
Senhas humanas possuem padrões e entropia limitada. A defesa precisa aumentar o custo de cada tentativa.
Salt impede precomputação compartilhada
Um salt aleatório e único é processado junto com a senha. Dois usuários com a mesma senha recebem hashes diferentes. Rainbow tables gerais deixam de servir para toda a base.
Salt não precisa ser secreto. Bibliotecas modernas o geram e armazenam no formato do hash. Implementação manual cria risco desnecessário.
Algoritmos especializados são caros de propósito
Argon2, scrypt, bcrypt e PBKDF2 permitem configurar custo. Argon2 e scrypt também exigem memória, reduzindo a vantagem de hardware paralelo.
Repetir SHA-256 manualmente não substitui uma construção revisada. Parâmetros, formato e resistência a ataques importam.
Parâmetros precisam acompanhar o hardware
O custo seguro hoje será barato no futuro. O hash armazenado deve incluir algoritmo e parâmetros. Após login bem-sucedido, a aplicação pode rehash com configuração atual.
Meça no hardware real com concorrência. Custo baixo ajuda o atacante; custo excessivo pode facilitar denial of service.
Pepper adiciona um segredo separado
Um pepper guardado fora do banco pode dificultar ataque quando somente a database vaza. Ele precisa de secret manager e plano de rotação.
Não substitui salt nem algoritmo forte. Perder o pepper pode impedir toda verificação, então operação importa.
Senhas não devem ser recuperáveis
Se o suporte envia a senha atual, ela está em plaintext ou criptografia reversível. Sistemas seguros apenas verificam e oferecem reset.
Reset tokens devem ser aleatórios, expirar, funcionar uma vez e ser armazenados com segurança. Logs nunca devem capturar senha.
Login não deve revelar contas
Mensagens e timing diferentes podem permitir enumeração. A aplicação pode executar um hash representativo para usuário inexistente e retornar erro neutro.
Rate limiting deve combinar conta, rede e sinais de abuso sem bloquear usuários legítimos permanentemente.
Normalização precisa permanecer estável
Espaços, acentos e Unicode devem virar os mesmos bytes em registro e login. Mudanças silenciosas de trimming ou normalization podem bloquear contas.
Se existe uma regra, documente e teste. Não “corrija” uma senha secretamente depois de armazenada.
Mudança de senha deve encerrar acessos antigos
Sessions, refresh tokens e links de recuperação podem continuar válidos. A política precisa decidir quais são revogados após reset ou incidente.
Notificações ajudam o usuário a reagir. Audit registre o evento e o canal, nunca o segredo.
Breaches exigem preparação
Hashing forte compra tempo, não torna a base inofensiva. A organização precisa saber parâmetros usados, forçar resets quando necessário, invalidar sessões e monitorar credential stuffing.
MFA, passkeys, password managers e screening de senhas vazadas complementam a proteção. Password storage é uma disciplina especializada, não uma chamada genérica de hash.
Parâmetros diferentes podem coexistir
Contas antigas podem usar bcrypt e novas Argon2. O formato armazenado deve indicar algoritmo e custo para que a função de verificação escolha corretamente. Após login, o sistema pode atualizar apenas aquele registro.
Essa convivência é preferível a uma migração que exija conhecer senhas em texto ou force reset sem necessidade.
Contas de serviço também precisam de política
Credenciais humanas e secrets de máquina possuem lifecycles diferentes. Uma senha de conta técnica armazenada como usuário ainda merece hashing forte, mas o ideal pode ser chave rotacionável ou workload identity.
Hashing não compensa secrets copiados em scripts, imagens Docker ou variáveis expostas. A proteção precisa cobrir criação, distribuição e revogação.
DoS por login deve ser considerado
Um algoritmo caro aumenta o custo do atacante offline, mas também consome recursos online. Rate limiting, filas e capacidade planejada evitam que requests anônimas esgotem CPU e memória.
O benchmark deve incluir picos de login e contas inexistentes, que podem executar uma verificação representativa para evitar enumeração.
Screening de senhas vazadas reduz risco recorrente
Impedir senhas presentes em grandes listas de credenciais comprometidas reduz o sucesso de credential stuffing. A consulta pode usar serviços com busca por prefixo ou uma base local, evitando enviar a senha completa. Essa verificação deve ocorrer no cadastro e na troca, sem registrar o valor consultado.
Regras arbitrárias como exigir muitos símbolos costumam gerar padrões previsíveis e piorar a experiência. Comprimento, bloqueio de senhas conhecidas e suporte a password managers produzem uma política mais útil. Passkeys e MFA diminuem a dependência de um único segredo memorizado.
Recuperação de conta faz parte do mesmo sistema
Um fluxo de reset fraco contorna o melhor password hash. Tokens devem ter alta entropia, validade curta, uso único e vínculo com a conta e a finalidade. Após a conclusão, o sistema precisa invalidar tokens pendentes e aplicar a política definida para sessões existentes.
Suporte administrativo também não deve escolher ou visualizar senhas. Exceções operacionais precisam produzir audit trail, notificação ao usuário e revisão, porque o caminho de recuperação frequentemente recebe menos atenção que o login principal.