Armazenar senhas no banco de dados: a história que ninguém te ensinou

Se o banco de dados do seu sistema vazasse hoje, quanto tempo um hacker demoraria pra decifrar a maioria das senhas? Minutos? Horas? Dias? Na minha visão, essa é a pergunta que quase nenhum programador sabe responder com segurança. A gente usa bcrypt, Argon2, bibliotecas prontas — mas e quando o banco inteiro vaza? Você realmente sabe se aquilo vai resistir ou desabar em segundos? Ninguém te ensinou a história de como chegamos aqui. Deixa eu contar.

Plaintext e os hashes "simples"

Nos anos 90, sites de verdade armazenavam senha em plaintext no banco de dados. Sem nada. Você fazia login, o servidor guardava aquele texto puro ali, e pronto. Se alguém invadia o banco, tinha acesso direto a tudo — era o caos.

Depois virou moda aplicar hash — MD5, SHA-1, SHA-512. Importante: essas funções NÃO foram desenhadas para senhas. Nasceram pra checksums, integridade de arquivos — o mercado simplesmente as reaproveitou. O fluxo era: cliente manda login+senha, servidor aplica hash e compara com o hash salvo no banco. Parecia seguro na época. Não era.

Rainbow tables: o ataque que quebra hashes genéricos

Aqui vem a confusão que a maioria tem: hash não é "desfazível". Um atacante não reverte o hash pra achar a senha original. O que ele faz é comparar o hash vazado contra uma tabela gigante pré-computada (rainbow table) de bilhões de senhas comuns. Se o hash bate com alguma entrada daquela tabela — acabou, a senha foi descoberta. Por isso hashes simples sem salt caem tão rápido: a mesma senha sempre gera o mesmo hash. Uma tabela pré-computada cobre 99% das senhas fracas instantaneamente.

Salt: quebrando as rainbow tables

A virada veio com salt — um valor aleatório único por usuário que você adiciona antes de fazer o hash. Dois usuários com a mesma senha agora geram hashes completamente diferentes. Isso quebra as rainbow tables genéricas porque cada combinação senha+salt é única. Um atacante é obrigado a atacar cada hash individualmente, e rainbow tables pré-computadas perdem o poder.

bcrypt e PBKDF2: CPU-hard não é suficiente

Depois vieram algoritmos desenhados especificamente para senhas. bcrypt e PBKDF2 têm um fator de custo — você configura quantas iterações, quanto tempo cada operação deve levar. De propósito fica lento, pra dificultar força bruta. Isso funciona, mas tem um detalhe: bcrypt é "CPU-hard", usa só ~4KB de memória por hash. GPU com milhares de núcleos consegue rodar milhões de instâncias em paralelo (GPU tem pouca memória por núcleo, mas MUITOS núcleos). No ataque massivo, bcrypt cai.

Argon2id: memory-hard vence paralelismo de GPU

Argon2id nasceu como resposta a esse problema. Venceu a Password Hashing Competition e é considerado hoje o estado da arte. A diferença crucial: é "memory-hard". Ele deliberadamente entope RAM do computador pra gerar cada hash — exige 32MB+ de memória RAM disponível. Isso quebra o paralelismo de GPU, porque GPU tem muita computação mas memória RAM limitada por núcleo. Não dá pra rodar milhões de instâncias em paralelo como acontecia com bcrypt. Você precisa de memória RAM real, e aí a GPU perde vantagem.

Pepper: segredo adicional fora do banco

Pra fechar, tem mais uma camada: pepper. É um segredo adicional (diferente do salt, que fica salvo junto no banco) guardado fora — variável de ambiente, secret manager, cofre seguro. Mesmo que o banco inteiro vaze, o atacante não tem o pepper, então nem consegue começar a quebrar os hashes. É defesa em profundidade: if salt breaks, pepper is your last line.

Por que isso importa pra você agora

Na prática, daqui pra frente: (1) Use Argon2id ou bcrypt se tiver que escolher agora — são o padrão industrial e a maioria das bibliotecas implementa bem. (2) Configure o fator de custo generosamente — se leva 500ms por hash no seu servidor, ok, o atacante paga o mesmo preço vezes bilhões pra quebrar seu banco inteiro. (3) Considere adicionar pepper se guardar credenciais sensíveis — é defesa gratuita que 99% dos devs negligencia. E se você estuda isso agora, você não será um desses 99%.

Quero aprender mais sobre segurança e arquitetura

Se esse tema de segurança te interessa e você quer construir sistemas arquitetonicamente sólidos, recomendo o curso do Renato Augusto "O Mapa do Arquiteto". O professor é excelente — já fiz o curso, recomendo de verdade. Essa visão abrangente de arquitetura (incluindo segurança, escalabilidade, design de banco de dados) é justamente o que falta pra maioria dos devs que aprendem linguagem mas nunca entendem a floresta.

Conclusão

Se o seu banco vazar amanhã, quanto tempo demora pra quebrar as senhas? Essa pergunta não é paranoia — é a diferença entre um incidente controlado e um desastre total. A história que contei aqui mostra exatamente por que hoje usamos Argon2, sal, e pepper — porque cada geração aprendeu com os ataques da geração anterior. Você agora sabe por que essas coisas existem. Use esse conhecimento.

Assista ao vídeo completo do Renato Augusto sobre esse tema em O QUE NINGUÉM TE ENSINOU SOBRE ARMAZENAR SENHAS NO BANCO DE DADOS.