Se você está iniciando sua jornada no mundo do desenvolvimento de software, provavelmente já ouviu falar em backend, autenticação e senhas. Mas será que você sabe como armazenar senhas de forma segura? E por que isso é tão importante?
Neste artigo, vamos explorar um dos pilares da segurança em aplicações: o hashing de senhas. Vamos entender por que nunca devemos armazenar senhas em texto claro, e como ferramentas como bcrypt e Argon2 nos ajudam a proteger os usuários — e sua reputação como desenvolvedor.
O erro mais comum: armazenar senhas em texto claro
Imagine que você está criando um sistema de cadastro. Um usuário se registra com o e-mail ana@email.com
e a senha senha123
. O que você faz com essa senha?
Se a resposta for:
"Salvo direto no banco de dados como
senha123
",
então você está cometendo um erro gravíssimo — e potencialmente perigoso.
Armazenar senhas em texto claro é como deixar a chave da sua casa debaixo do tapete. Se alguém invadir seu banco de dados (e isso acontece mais do que você imagina), terá acesso direto a todas as contas dos seus usuários.
E não estamos falando de cenários hipotéticos.
A solução: hashing de senhas
Para proteger as senhas, usamos uma técnica chamada hashing. Um hash é como uma "impressão digital" única de um dado. Ele transforma uma senha como senha123
em algo como:
$argon2id$v=19$m=196608,t=2,p=1$c...
Esse valor é irreversível — ou seja, mesmo que um atacante tenha o hash, não pode recuperar a senha original.
Mas não basta usar qualquer função de hash. Funções como MD5 ou SHA-256 são rápidas demais — e isso as torna inseguras para senhas. Atacantes podem testar bilhões de combinações por segundo com GPUs poderosas.
É aí que entram ferramentas como bcrypt e Argon2.
Ambos são algoritmos projetados para serem lentos de propósito — isso dificulta ataques de força bruta. Mas há diferenças importantes:
bcrypt | Argon2 |
---|---|
Criado em 1999, amplamente usado | Vencedor do Password Hashing Competition em 2015 |
Resistente a ataques comuns | Mais resistente a ataques com GPU e hardware especializado |
Parâmetros: custo (número de iterações) | Parâmetros: tempo, memória e threads (mais flexível) |
Seguro, mas mais antigo | Estado da arte em segurança |
Por que isso importa para você, que está iniciando a jornada como desenvolvedor de software?
Porque segurança é parte do nosso escopo de trabalho, nossa responsabilidade.
Você pode criar a interface mais bonita, a API mais rápida, mas se um vazamento de dados ocorrer por causa de senhas mal armazenadas, a culpa será sua — e do seu código.
Além disso, empresas hoje em dia exigem que desenvolvedores entendam de segurança básica. Saber como proteger dados sensíveis é um diferencial competitivo.
Deixo uma lista simples, mas direta, com práticas que todo iniciante deve seguir
- Nunca armazene senhas em texto claro. Nunca.
- Sempre use algoritmos lentos como bcrypt ou Argon2.
- Deixe o salt (valor aleatório incrementado no processo de hashing) ser gerado automaticamente — essas bibliotecas fazem isso por você.
- Atualize os parâmetros periodicamente (ex: aumentar o custo do bcrypt conforme o hardware evolui).
- Teste seu código: verifique se o hash muda a cada nova senha, mesmo que seja igual.
Se você quiser se aprofundar um pouco mais no assunto, confira essas referências
OWASP Password Storage Cheat Sheet
→https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
O guia mais confiável sobre armazenamento seguro de senhas.
NIST Digital Identity Guidelines (SP 800-63B)
→ https://pages.nist.gov/800-63-3/sp800-63b.html
Diretrizes oficiais dos EUA sobre autenticação e senhas.
Password Hashing Competition (PHC)
→ https://password-hashing.net
O concurso que escolheu o Argon2 como o futuro do hashing de senhas.
Documentação do Argon2
→ https://github.com/ranisalt/node-argon2
Documentação do bcryptjs
→ https://www.npmjs.com/package/bcryptjs
E mantenha isso em mente:
Começar na carreira de desenvolvimento é emocionante. Há tantas coisas para aprender, como frameworks, bancos de dados, APIs… Mas não subestime a importância da segurança desde o início do processo de planejamento de qualquer sistema.
Proteger senhas não é um "extra". É uma necessidade. Um bom desenvolvedor escreve código que funciona. Um ótimo desenvolvedor escreve código que é seguro.
E você pode — e deve — ser um ótimo desenvolvedor.
Top comments (0)