Dê o próximo passo e inicie sua carreira
Dê o próximo passo e inicie sua carreira agora mesmo
5 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Criando um repositório remoto em GitHub
Ler mais
Fazendo o deploy de uma aplicação Django
Ler mais
Funcionalidade: sugestão de edição de conteúdo no Alura
Ler mais
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.
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.
A pessoa usuária não precisa decorar o código gigante. Quando ele tenta acessar o sistema:
Se os códigos forem iguais, o acesso é liberado. Assim, comparamos apenas os resultados da função, sem nunca precisar guardar a senha real.
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:
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.
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 |
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.
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:
Dominar essas práticas é o que diferencia o desenvolvimento comum de um software verdadeiramente preparado para os desafios atuais.
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.
Avalie este artigo