O que aplicar hash a uma senha realmente protege

A versão curta

Aplicar hash a uma senha protege os usuários quando seu banco de dados de senhas é roubado.

Esse é o trabalho principal. Não o único detalhe, nem todo o modelo de segurança, mas a razão central pela qual aplicamos hash a senhas em vez de armazená-las diretamente.

Uma senha com hash adequado é difícil de reverter. Se um invasor obtiver uma cópia da sua tabela de usuários, ele não deve descobrir imediatamente que a senha de Alice é Spring2026!. Em vez disso, ele obtém um hash armazenado que exige tempo, dinheiro e hardware para ser testado contra palpites.

Essa distinção importa. O hash de senhas não foi feito para tornar o login seguro por si só. Ele não impede phishing. Ele não impede alguém de tentar senhas vazadas contra seu formulário de login. Ele não protege um cookie de sessão após o login. Ele compra tempo e reduz danos depois de uma falha muito específica: o armazenamento dos seus verificadores de senha fica exposto.

Se você entender esse limite, tomará decisões melhores sobre algoritmos, fatores de custo, redefinições, logs e resposta a incidentes.

O que é um hash de senha

Um hash de senha é a saída de uma função unidirecional aplicada a uma senha, geralmente com um salt único e um algoritmo de hash de senha deliberadamente lento.

Quando um usuário cria uma conta, o sistema deve fazer aproximadamente isto:

1. Receber a senha por HTTPS.
2. Gerar um salt aleatório e único.
3. Processar a senha e o salt por meio de uma função de hash de senha como Argon2id, bcrypt, scrypt ou PBKDF2.
4. Armazenar o nome do algoritmo, os parâmetros, o salt e o hash resultante.
5. Descartar a senha original.

Quando o usuário faz login depois, o sistema repete o mesmo processo de hash com a senha enviada e os parâmetros armazenados. Se o hash resultante corresponder ao hash armazenado, o login é bem-sucedido.

A parte importante: a aplicação não precisa saber a senha original. Ela só precisa verificar que a senha enviada produz o resultado esperado.

É por isso que armazenar senhas com criptografia reversível costuma ser o modelo errado. Se sua aplicação consegue descriptografar todas as senhas, qualquer pessoa que roube a chave de descriptografia pode fazer o mesmo. Senhas normalmente devem ser inverificáveis no sentido reverso, não apenas ocultas.

Do que o hash protege você

1. Divulgação imediata de senhas após uma violação de banco de dados

Se um invasor rouba um banco de dados contendo senhas em texto claro, o dano é instantâneo. Todas as senhas ficam expostas. Os usuários correm risco não apenas no seu site, mas em qualquer lugar onde tenham reutilizado essa senha.

Se o banco de dados contém senhas bem hasheadas, o invasor tem mais trabalho a fazer. Ele precisa adivinhar senhas candidatas, aplicar hash a cada palpite com o salt e os parâmetros corretos, e comparar o resultado.

Para senhas fracas, isso ainda pode ser rápido. Para senhas fortes e únicas, pode ser impraticável.

O hash transforma uma divulgação catastrófica em uma corrida: os usuários conseguem redefinir senhas, e você consegue conter o incidente antes que os invasores quebrem muitas delas?

Isso não é perfeito. Ainda é uma violação. Mas é um modo de falha drasticamente melhor.

2. Ataques em massa contra toda a sua base de usuários

Salts são uma parte essencial do armazenamento de senhas porque impedem que invasores ataquem muitos usuários de forma eficiente de uma só vez com tabelas pré-computadas.

Um salt não é secreto. Ele é armazenado junto do hash. Seu papel é a unicidade.

Se dois usuários escolhem a mesma senha, salts únicos garantem que seus hashes armazenados sejam diferentes. Isso impede que invasores vejam de imediato que muitos usuários compartilham a mesma senha. Também impede ataques clássicos com rainbow tables, em que invasores usam enormes listas pré-computadas de mapeamentos de senha para hash.

Sem salts, um hash quebrado pode revelar todos os usuários com a mesma senha. Com salts, cada palpite de senha precisa ser testado separadamente para cada usuário.

3. Adivinhação offline rápida

Depois que invasores têm um banco de dados de senhas, eles podem fazer tentativas offline. Isso significa que seus limites de taxa de login, CAPTCHA, bloqueio de IP e monitoramento deixam de importar. O invasor pode testar palpites no próprio hardware.

É aqui que a escolha do algoritmo importa.

Hashes de uso geral, como SHA-256 e SHA-512, são projetados para serem rápidos. Isso é bom para integridade de arquivos e assinaturas digitais. É ruim para armazenamento de senhas.

Algoritmos de hash de senha são projetados para serem lentos, ajustáveis e, às vezes, resistentes por uso de memória. Argon2id, bcrypt, scrypt e PBKDF2 permitem ajustar parâmetros de custo para que cada palpite leve um tempo significativo.

Argon2id é amplamente recomendado para novos sistemas porque pode ser configurado para exigir tanto tempo de CPU quanto memória, o que torna a quebra em larga escala com GPU mais cara. bcrypt continua comum e aceitável quando bem configurado, embora tenha limitações como o tratamento do comprimento da senha. PBKDF2 ainda é usado em alguns ambientes orientados por conformidade, especialmente onde componentes validados por FIPS são exigidos.

O princípio é simples: tornar logins legítimos aceitavelmente rápidos, enquanto torna bilhões de palpites caros.

Do que o hash não protege você

1. Phishing

Se um usuário digita a senha em uma página de login falsa, o hash no seu servidor não ajuda. O invasor recebe a senha antes que seu sistema sequer a veja.

As defesas aqui são diferentes: autenticação multifator, passkeys, educação de usuários, higiene de domínio, autenticação resistente a phishing e fluxos cuidadosos de redefinição de senha.

O hash de senhas é uma contenção para segredos armazenados. Não é uma defesa contra usuários serem enganados a entregar esses segredos.

2. Credential stuffing

Credential stuffing acontece quando invasores pegam pares de nome de usuário e senha vazados de um serviço e os testam em outro.

Seus hashes de senha podem ser excelentes, e credential stuffing ainda pode funcionar se os usuários reutilizarem senhas.

Esse é um ataque online contra seu formulário de login, não um ataque offline contra seu banco de dados. Você precisa de limitação de taxa, detecção de anomalias, verificações de senhas comprometidas, MFA e políticas sensatas de bloqueio que não criem oportunidades fáceis de negação de serviço.

O mesmo raciocínio prático se aplica a qualquer formulário exposto. Se você está revisando sua superfície de autenticação, vale a pena ler sobre por que seu formulário de contato é sua maior responsabilidade de spam; os mecanismos são diferentes, mas a lição é semelhante: entradas públicas precisam de controles contra abuso, não apenas de código backend limpo.

3. Senhas capturadas em logs ou analytics

O hash só ajuda se a senha em texto claro for descartada rapidamente e nunca copiada para outro lugar.

Falhas comuns incluem:

• Registrar corpos completos de requisições em tentativas de login malsucedidas.
• Enviar senhas para ferramentas de monitoramento de erros.
• Capturar campos de senha em produtos de replay de sessão.
• Incluir credenciais em URLs durante fluxos de redefinição ou migração mal projetados.
• Armazenar senhas temporárias em texto claro durante importações.

Esses erros contornam completamente o hash de senhas. Se o texto claro chega a logs, backups, data warehouses ou ferramentas de terceiros, sua função de hash é irrelevante.

Trate campos de senha como dados tóxicos. Redija-os antes de registrar logs. Exclua-os de analytics. Mantenha-os fora de URLs. Limite quem pode acessar traces de produção.

4. Segurança de sessão ruim

Após o login, o navegador do usuário geralmente recebe um cookie ou token de sessão. Se esse token for roubado, o invasor pode nem precisar da senha.

O hash de senhas não protege contra cross-site scripting, cookies inseguros, fixação de sessão, geração fraca de tokens ou tempos de vida de sessão longos demais.

Cookies de sessão merecem sua própria revisão: HttpOnly, Secure, SameSite apropriado, sessões de alto risco de curta duração e invalidação no servidor após mudanças de senha. O panorama mais amplo de privacidade e navegadores também continua mudando, como abordado em o que mudou para cookies em 2026.

5. Redefinição de senha e recuperação de conta fracas

Muitas tomadas de conta não começam com a senha. Elas começam com o fluxo de redefinição.

Se tokens de redefinição são previsíveis, têm vida longa, vazam por cabeçalhos de referrer ou são enviados para contas de email comprometidas, o hash de senhas não vai salvar você.

Use tokens de redefinição de alta entropia, janelas curtas de expiração, uso único e notificações claras ao usuário. Como o email muitas vezes é o canal de recuperação, a autenticação básica de domínio também importa. Se sua equipe trata registros DNS como um ritual misterioso, comece com um tour amigável para desenvolvedores por MX, SPF, DKIM e DMARC.

A escolha do algoritmo: o que usar agora

Para novas aplicações, use Argon2id se sua plataforma oferecer bom suporte. Ele é o vencedor da Password Hashing Competition e foi projetado para armazenamento de senhas, incluindo resistência à quebra intensiva com GPU.

Uma hierarquia moderna razoável se parece com isto:

1. Argon2id para novos sistemas quando disponível.
2. bcrypt quando Argon2id não é prático e o suporte a bcrypt é maduro.
3. scrypt quando a configuração resistente por uso de memória tem bom suporte.
4. PBKDF2 quando exigido por restrições de plataforma ou conformidade.

Evite SHA-256, SHA-512, MD5 simples ou uma combinação caseira como sha256(password + salt). Hashes rápidos não são funções de armazenamento de senhas. Construções personalizadas engenhosas tendem a ser piores do que opções padronizadas e sem graça.

Também evite inventar sua própria política de senhas em torno de detalhes triviais de algoritmo. Usuários não se beneficiam de uma lista de 12 regras de composição de senha se ela os empurra para padrões previsíveis. Senhas mais longas e únicas, gerenciadores de senha, triagem de senhas comprometidas e MFA geralmente importam mais.

Fatores de custo não são configure-e-esqueça

O hash de senhas tem parâmetros. Argon2id tem memória, iterações e paralelismo. bcrypt tem um fator de custo. PBKDF2 tem uma contagem de iterações.

Esses valores devem ser escolhidos com base no seu ambiente de produção. Baixos demais, e os invasores fazem palpites a baixo custo. Altos demais, e seu sistema de login fica lento ou vulnerável a negação de serviço.

Um alvo prático costuma estar na faixa de dezenas a algumas centenas de milissegundos por verificação de senha nos seus servidores reais, dependendo do tráfego e do risco. Sistemas de alta segurança podem escolher mais. Sistemas em escala de consumo podem precisar de planejamento cuidadoso de capacidade.

Não copie um fator de custo de um post de blog de cinco anos atrás. O hardware muda. As bibliotecas mudam. Seu tráfego muda.

Revise os parâmetros periodicamente e planeje o rehashing. Um padrão comum é armazenar o algoritmo e os parâmetros com cada hash. Em um login bem-sucedido, se os parâmetros armazenados estiverem desatualizados, aplique hash novamente à senha enviada com a configuração mais nova e atualize o registro.

Peppers: úteis, mas não substitutos

Um pepper é um valor secreto adicionado ao processo de hash de senha e armazenado separadamente do banco de dados, muitas vezes em um gerenciador de segredos ou módulo de segurança de hardware.

Diferentemente de um salt, um pepper deve permanecer secreto.

Peppers podem reduzir danos se o banco de dados vazar, mas os segredos da aplicação não. Eles são mais úteis em ambientes maduros com boa gestão de chaves. São menos úteis se o mesmo invasor puder roubar tanto o banco de dados quanto a configuração da aplicação.

Se você usa um pepper, planeje a rotação com cuidado. Rotacioná-lo pode exigir que os usuários façam login novamente ou redefinam senhas, dependendo do desenho. Um pepper é uma camada adicional, não uma razão para enfraquecer as configurações do hash subjacente.

A lista de verificação operacional

Se você é responsável por um sistema real, a lista de verificação prática é curta:

• Armazene senhas apenas com um algoritmo padrão de hash de senha.
• Use um salt aleatório único por senha.
• Prefira Argon2id para novas implementações.
• Ajuste parâmetros de custo em hardware semelhante ao de produção.
• Armazene algoritmo e parâmetros com cada hash.
• Faça rehash no login quando os parâmetros ficarem desatualizados.
• Nunca registre senhas em logs nem as envie para ferramentas de analytics.
• Use TLS em todos os lugares onde credenciais são enviadas.
• Adicione MFA ou passkeys quando o risco justificar.
• Proteja fluxos de redefinição com a mesma seriedade dos fluxos de login.
• Tenha um plano de incidente para redefinições forçadas e notificação de usuários.

O hash de senhas não é glamouroso. É encanamento. Mas é o tipo de encanamento que determina se uma violação se torna um incidente doloroso ou um desastre para todos os usuários.

<!-- tool-cta:start -->

💡 Experimente isto: Veja como a mesma entrada é mapeada para diferentes algoritmos com o Hash Generator, que torna concreta a diferença entre hashes rápidos e hashes de nível adequado para senhas.

<!-- tool-cta:end -->

O modelo mental honesto

A melhor forma de pensar sobre hash de senhas é esta:

O hash não protege a senha enquanto o usuário a digita. Não protege a conta depois que o usuário está logado. Não protege usuários que reutilizam senhas pela web.

Ele protege o verificador armazenado.

Isso parece restrito, mas é extremamente importante. Bancos de dados vazam. Backups vazam. Sistemas de staging são copiados. Fornecedores recebem acesso que não deveriam ter. Exportações antigas ficam em armazenamento de objetos por mais tempo do que alguém se lembra.

Quando isso acontece, o desenho do seu armazenamento de senhas se torna a diferença entre invasores receberem senhas e invasores receberem um problema caro de adivinhação.

É disso que aplicar hash a uma senha realmente protege você.