Hash de senhas
Por que senhas nunca são guardadas, nem criptografadas, e quais algoritmos resistem a um vazamento do banco.
O problema: o banco vai vazar
Projete o armazenamento de senhas supondo que o banco vai parar nas mãos de alguém. Um backup esquecido num bucket público, uma injeção de SQL ou um funcionário com acesso demais bastam. Quando isso acontece, a pergunta deixa de ser se o atacante tem os dados e passa a ser o que ele consegue fazer com eles.
A resposta importa além do seu sistema. A maioria das pessoas repete a mesma senha em vários lugares. Uma senha descoberta no seu banco abre o e-mail, o banco e as redes sociais do usuário.
Três formas erradas de guardar uma senha
| Forma | Como fica no banco | Por que falha |
|---|---|---|
| Texto puro | minhasenha123 | O vazamento entrega todas as senhas na hora |
| Criptografada | Senha cifrada com uma chave | A chave mora no mesmo servidor e costuma vazar junto; com ela, tudo volta ao texto |
| Hash rápido (MD5, SHA-1, SHA-256) | ef92b778bafe... | Uma placa de vídeo calcula bilhões desses hashes por segundo e testa listas inteiras de senhas |
A criptografia é a armadilha mais comum, porque soa segura. Mas criptografia é reversível por definição: existe uma chave que desfaz a operação. O sistema nunca precisa saber a senha original, só conferir se a digitada é igual. Para isso, basta uma operação de mão única.
Hash: uma operação de mão única
Uma função de hash transforma qualquer texto numa sequência de tamanho fixo. Ela tem três propriedades úteis aqui:
- O mesmo texto sempre gera o mesmo resultado.
- Uma mudança mínima no texto muda o resultado por completo.
- Não existe forma de calcular o texto a partir do resultado.
No cadastro, o sistema guarda o hash da senha. No login, calcula o hash da senha digitada e compara. Se forem iguais, a senha está certa, e a original nunca foi guardada.
| Operação | Volta ao original? | Uso |
|---|---|---|
| Codificação (Base64) | Sim, sem chave nenhuma | Transportar dados em outro formato |
| Criptografia (AES) | Sim, com a chave | Proteger dados que precisam ser lidos depois |
| Hash (Argon2, SHA-256) | Não | Conferir sem guardar o original |
Por que um hash rápido não serve
A única forma de reverter um hash é tentar: calcular o hash de cada senha candidata e comparar. É aí que a velocidade vira problema.
O SHA-256 foi feito para ser rápido, porque é usado para verificar arquivos e assinaturas. Uma única placa de vídeo comum calcula bilhões de SHA-256 por segundo. Com uma lista das senhas mais usadas e suas variações, a maior parte das senhas de um banco vazado cai em minutos.
A defesa é inverter a lógica: usar uma função lenta de propósito. Se cada tentativa custa um décimo de segundo, o login do usuário nem percebe, e o atacante passa a precisar de anos para testar a mesma lista.
Os algoritmos próprios para senha são assim. Alguns também exigem muita memória por tentativa, o que anula a vantagem das placas de vídeo, que têm milhares de núcleos e pouca memória para cada um.
O sal
Mesmo com uma função lenta, sobram dois problemas se o hash for calculado só sobre a senha:
- Dois usuários com a mesma senha teriam o mesmo hash. Descobrir um é descobrir todos.
- O atacante poderia calcular os hashes das senhas comuns uma única vez e reaproveitar a tabela em qualquer banco vazado.
O sal resolve os dois. É um valor aleatório, diferente para cada usuário, misturado à senha antes do hash. Ele não é segredo: fica guardado ao lado do hash. A função dele é tornar cada hash único e obrigar o atacante a recomeçar o trabalho para cada usuário.
Como o resultado fica guardado
Os algoritmos modernos guardam tudo numa única string: o algoritmo, os parâmetros de custo, o sal e o hash.
$argon2id$v=19$m=19456,t=2,p=1$c2FsdGFsZWF0b3Jp$HnZ3R0m4...
algoritmo custo sal hashIsso tem duas consequências práticas. Não é preciso uma coluna para o sal: a biblioteca extrai tudo da string na hora de conferir. E dá para aumentar o custo com o tempo: hashes antigos continuam válidos com os parâmetros deles, e os novos usam parâmetros mais fortes.
Por que isso importa quando a IA escreve o código
Assistentes acertam o algoritmo com mais frequência hoje, mas os erros em volta dele continuam aparecendo:
- Usar SHA-256 com sal "porque é seguro", sem perceber que é rápido demais.
- Usar parâmetros de custo baixos copiados de um exemplo antigo.
- Comparar o hash com
==, o que pode vazar informação pelo tempo de resposta. - Responder mais rápido quando o e-mail não existe, revelando quais contas estão cadastradas.
- Nunca atualizar os hashes antigos quando o custo recomendado sobe.
O próximo nível compara os algoritmos e mostra como escolher os parâmetros.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Hash de senhas em cinco minutos
Explique em no máximo cinco minutos de leitura como um sistema deve guardar as senhas dos usuários, para alguém que programa mas nunca estudou segurança. Cubra só o essencial: por que não guardar a senha nem criptografá-la, o que é um hash, por que o SHA-256 não serve para senhas, o que é o sal e quais algoritmos usar. Use uma analogia simples. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
Pensar como quem roubou o banco
Quero entender o armazenamento de senhas pelo ponto de vista de um atacante que conseguiu uma cópia do banco de dados. Aja como um especialista em segurança. Pergunte primeiro qual é a minha experiência com segurança e em qual linguagem eu trabalho. Depois, apresente o mesmo banco com as senhas guardadas de cinco formas, uma por vez: texto puro, criptografadas com AES, hash MD5 sem sal, hash SHA-256 com sal e Argon2id. Para cada uma, pergunte o que eu faria como atacante e quanto tempo levaria, antes de explicar. Use estimativas realistas de velocidade de placas de vídeo atuais, dizendo que são aproximadas. Ao final, peça que eu explique com minhas palavras por que lentidão e consumo de memória são qualidades num algoritmo de senha, e corrija o que estiver impreciso.
Hash, criptografia e codificação
Quero parar de confundir hash, criptografia e codificação. Explique as três operações com exemplos concretos: o que cada uma faz, se é reversível, se usa chave e para que serve no backend. Use Base64, AES e SHA-256 como exemplos, e depois explique onde entram os algoritmos de senha como Argon2 e bcrypt. Em seguida, me apresente oito situações, uma por vez, e pergunte qual das operações eu usaria: guardar senhas, guardar o número do cartão que precisa ser cobrado depois, enviar um arquivo binário dentro de um JSON, verificar se um arquivo baixado foi alterado, guardar o CPF que aparece mascarado na tela, gerar um identificador para um link de redefinição de senha, guardar tokens de API dos clientes e assinar um webhook. Corrija cada resposta explicando o motivo.
Sal, pimenta e o formato do hash
Quero entender em detalhe o que é o sal, o que é a pimenta e como uma string de hash moderna é organizada. Explique: 1. Os dois problemas que o sal resolve, com um exemplo de dois usuários com a mesma senha e de uma tabela de hashes pré-calculados. 2. Por que o sal não precisa ser secreto, e onde ele fica guardado. 3. A anatomia de uma string Argon2id e de uma string bcrypt, campo por campo. 4. Como esse formato permite aumentar o custo ao longo dos anos sem invalidar as senhas existentes. 5. O que é a pimenta, onde ela fica, o que acrescenta e os riscos operacionais dela. Faça uma pergunta de verificação depois de cada parte e espere a minha resposta antes de continuar.