6 minutos de leitura
O uso de autenticação está presente em quase todas as aplicações, desde fóruns e redes sociais até sistemas bancários e corporativos.
Ao desenvolver um projeto, o cuidado com as credenciais das pessoas usuárias deve ser prioridade. Ainda é comum encontrar estruturas de dados que armazenam informações de forma exposta, como no exemplo abaixo:
| Nome | Login | Senha |
| Guilherme | guicosta | minha_senha_segura |
| Luana | luana_sc | minha_senha_segura |
O que aconteceria com a credibilidade do seu produto se um invasor acessasse essa tabela?
Muitas vezes, o argumento utilizado é que o banco de dados está isolado em uma rede local e não exposto à internet. Mas, isso não garante proteção total.
Embora as empresas geralmente isolem ambientes de produção e usem dados fictícios para testes, as informações reais ainda podem ser acessadas por perfis com privilégios administrativos.
Se uma pessoa usuária interna com más intenções ou uma conta de administrador comprometida executar um comando de consulta, todos os dados estarão vulneráveis.
A regra de ouro é clara: nunca armazene senhas em texto puro no banco de dados.
O uso de Hashes para proteção de dados
Se não devemos armazenar a senha bruta, qual a alternativa? A técnica padrão é transformar a senha em uma sequência de caracteres que parece aleatória, chamada de hash.
Veja como a tabela ficaria:
| Nome | Login | Hash da Senha |
| Guilherme | guicosta | 4f24ed619ffb73b8792e3f74e5ffa3bb |
| Luana | luana_sc | de1dc74c5561739cbe4c6368f78e9b6f |
Uma função de hash recebe um texto e o mapeia para uma cadeia de caracteres de tamanho fixo. O ponto principal é que esse processo é unidirecional: a partir do código gerado, é inviável descobrir a senha original.
Como funciona o login com Hash?
A pessoa usuária não precisa decorar o código gigante. Quando ele tenta acessar o sistema:
- A pessoa usuária digita a senha comum.
- A aplicação calcula o hash dessa senha digitada.
- O sistema compara o novo hash gerado com o que está guardado no banco de dados.
Se os códigos forem iguais, o acesso é liberado. Assim, comparamos apenas os resultados da função, sem nunca precisar guardar a senha real.
O hash sozinho é suficiente?
Embora esconda a senha, o hash puro ainda tem vulnerabilidades. Alguém com acesso à tabela pode comparar seus hashes com listas de senhas comuns já convertidas (conhecidas como Rainbow Tables). Por exemplo:
- Hash de "123456" será sempre e10adc3949ba59abbe56e057f20f883e em algoritmos simples.
Se o invasor souber que esse código corresponde ao "123456", ele descobre a senha de todos os usuários que usam essa combinação básica.
Dificultando ataques com Salt (Sal)
Se buscarmos em nossa tabela pelos hashes gerados, ainda conseguiremos identificar quem utiliza senhas comuns como 123456. Para evitar isso, não calculamos o hash apenas da senha bruta. Nós a combinamos com um valor aleatório antes de gerar o código final.
Por exemplo, em vez de gerar o hash de abcdef, geramos o hash de abcdef + HjJK8L. Isso resulta em um código completamente diferente e imprevisível.
Para que essa estratégia funcione, cada pessoa usuária deve ter um "sal" (salt) exclusivo. Caso contrário, um invasor que descubra o padrão do texto aleatório poderia recalcular as senhas mais comuns facilmente. Com um salt único por usuário, a tabela assume este formato:
| Nome | Login | Hash da Senha | Salt |
| Guilherme | guicosta | 2bcc9ee9b953cd813008f18f7748656 | 37hsis2m |
| Luana | luana_sc | 6da49cd9bc606d9bcdb141cd9364e145 | 83nc0m20 |
Por que não usar Criptografia?
Muitas pessoas confundem os termos, mas há uma diferença fundamental: a criptografia é reversível. Por definição, se você possui a chave e o texto cifrado, consegue voltar ao dado original.
Se a base de dados for acessada indevidamente, o invasor precisará apenas encontrar a chave de segurança. Se a chave for fraca, pode ser descoberta por força bruta; se for forte, ela ainda precisará estar armazenada em algum lugar acessível ao sistema (e consequentemente a quem o gerencia).
O uso de Hash + Salt elimina essa vulnerabilidade, pois o dado original não pode ser recuperado, apenas comparado.
Conclusão
Garantir a proteção das credenciais é um passo fundamental no desenvolvimento de qualquer projeto. Embora nenhuma barreira seja absoluta, adotar boas práticas dificulta o acesso a dados sensíveis.
Se você deseja ir além e entender como proteger aplicações de ponta a ponta, a Alura oferece a carreira de AppSec: Desenvolvimento Seguro de Aplicações. Nela, você percorre uma trilha completa que vai desde os fundamentos de criptografia e redes até níveis avançados de:
- SSDLC e OWASP Top 10: Para aprender a mitigar as vulnerabilidades mais comuns em APIs e aplicações web.
- DevSecOps: Integrando testes automáticos de segurança (SAST, DAST e SCA) diretamente no fluxo de desenvolvimento.
- Estratégia e Liderança: Aplicando padrões internacionais de verificação de segurança e gestão de riscos.
Dominar essas práticas é o que diferencia o desenvolvimento comum de um software verdadeiramente preparado para os desafios atuais.
Continue evoluindo em Segurança de Aplicações
Proteger senhas com hash e salt é apenas uma das camadas necessárias para desenvolver aplicações realmente seguras. Na carreira AppSec: Desenvolvimento Seguro de Aplicações da Alura, você aprende como identificar vulnerabilidades, aplicar boas práticas de autenticação e proteger APIs e aplicações web contra os riscos mais comuns do mercado.
A trilha aborda temas como SSDLC, OWASP Top 10, DevSecOps, modelagem de ameaças, gerenciamento de segredos e segurança em APIs, ajudando você a construir sistemas mais preparados para os desafios atuais de cibersegurança.
