O salt é utilizado no processo de hashing para forçar sua unicidade. O salt aumenta a complexidade do hash. Sem onerar ou dificultar a senha do usuário. E com isso se proteger de ataques como Rainbow tables.

O Hash

O Hash é uma função deterministica. Isso quer dizer que, dada uma certa entrada, ela produzirá sempre a mesma saída.

Adicionar um salt aleatório, garante que o hash produzido será sempre diferente. Isso protege seu repositório de um Rainbow table attack. E diminui a eficácia de um brute force ou dictionary attack.

Entendendo o problema

Supondo que um usuário tenha uma senha 12345678. O hash gerado será 25D55AD283AA400AF464C76D713C07AD (MD5).

Repare na tabela os usuários bruno e joão. Apesar de não saber o password é possivel identificar que eles possuem o mesmo hash. Como o hash é deterministico. É válido afirmar que ambos possuem a mesma senha.

Antes de continuar veja o que já passou

Se você chegou aqui neste artigo e não leu os anteriores, é leitura obrigatória para entender como chegamos aqui:

• Segurança - Parte 1 - Como armazenar senhas
• Segurança - Parte 2 - Hash em senhas.

Como hashes são crackeados

Os métodos mais conhecidos atualmente para crackear um hash são:

• Dictionary attack
• Brute Force attack
• Lookup Table
• Reverse Lookup Table
• Rainbow Tables

O salt protege seu repositório de três deles. Lookup table, reverse lookup e rainbow table.

Dictionary e Brute force attack

A maneira mais fácil de crakear um password é por tentative error. E nesse caso, os ataques mais comuns são dictionary e brute force.

O brute force é o método mais lento. No entanto, uma maquina mediana. Com duas placas de video ATI Radeon 7970 (R$ 800.00 no Mercado Livre) e utilizando o hashcat. Consegue calcular um password de 6 caracteres. Incluindo todas as letras minusculas, maiusculas, numeros e caracteres especiais do teclado: Em miseros 47 segundos. Mais detalhes sobre isso em Segurança - Parte 2 - Hash em senhas.

O brute force tenta todas as possibilidades de combinações de caracteres, incluindo letras, números e caracteres especiais.

Já o dictionary attack é um ataque mais efetivo, quando comparado ao brute-force. Pois utiliza palavras. Alguns dicionarios, possuem uma coleção de senhas de outros bancos de dados vazados, aumentando ainda mais sua efetividade.

Lookup table

Essa é uma técnica bem efetiva. Ao invés calcular o Hash apartir da senha. Ele utiliza uma tabela com milhares de hashes já calculados.

Reverse Lookup table

Esta técnica permite ao atacante aplicar um dictionary ou brute force a diversos hashes simultaneamente. Ao invés de atacar um usuário até tentar quebrar sua senha. Gera um hash e tenta localizar todos os usuários que possuem aquela senha.

Rainbow table

Um Rainbow table requer duas coisas: uma função de hashing e outra de reduction.
E através de um processo de hash e reduction, cria uma chain para mapear e diminuir o consumo de memória, sem ter que ficar calculando o hash de cada senha. É um processo complexo. Mas funciona muito similar ao Lookup table.

São considerados time-memory trade-off. Isso é basicamente quando você aceita um tempo de execução mais longo em favor de menos requisitos de memória. Com essa tecnica o tamanho das tabelas pode ser extremamente reduzido. Mas ainda assim elas são gigantescas. Veja algumas tabelas para download aqui.

Para entender mais sobre como funciona rainbow-tables, acesse essa documentação.

Salt

Lookup tables e Rainbow tables só funcionam porque cada senha é hasheada exatamente da mesma maneira.

Se dois usuários tiverem a mesma senha, eles terão os mesmos hashes. É possivel evitar isso adicionando um salt ao hash.

O salt é uma string aleatória. Que pode ser concatenado (préfixando ou pós-fixando) na senha.

Isso torna o hash de uma senha em uma string completamente diferente. Para verificar se uma senha está correta, é necessário o salt. Ela é normalmente armazenada no repositório no mesmo local do hash, ou junto dele.

O salt não precisa ser secreto. Só o fato de randomizar a Hash já é o suficiente para tornar as Lookup table e rainbow table ineficazes.

Um atacante não saberá com antecedência qual será o salt, portanto, não conseguirá pré-calcular uma Lookup table ou uma rainbow table.

O salt precisa ser aleatório, assim o ataque Reverse Lookup table também será ineficiente.

Não crie seu próprio salt

Aqui vale a mesma regra para hash de senhas. Nunca crie salt. Existem bibliotecas já desenvolvida com esse próposito. Funções de hash são incrivelmente complexas, assim como as de salt.

Só crie seu salt em último caso.

Salts ineficientes

Utilizar um único salt, tem o mesmo efeito que não utilizar nenhum. Na prática dois usuários com a mesma senha terá o mesmo hash. Perdendo totalmente seu objetivo.

Um salt deve ser grande, pois senão o atacante poderá montar Lookup tables ou Rainbow attack em cima do Salt.

Uma regra comumente utilizada é usar um salt com o mesmo tamanho da saída da função hash. Por exemplo, se utilizar o algoritimo SHA256, de 256 bits o salt deve ter 256bits aleatórios.

Playground

Quer saber o quão poderoso é um Lookup table? Vá até este site e coloque esses hashes:

Conclusão

Salt, assim como o hash de senha é uma segunda linha de defesa. O atacante já está com acesso ao repositório. Seja por um SQL Injection, ou porque extraviou a fita de backup. Pode ser um dev ou DBA da própria empresa.

Seus usuários estão inserindo a senha deles seu aplicativo. Estão confiando em você a segurança deles.

Se a primeira linha de defesa for quebrada e as senhas de seus usuários estiverem desprotegidas, os hackers poderão usar essas senhas para comprometer as contas outros sites e serviços. A maioria das pessoas utiliza a mesma senha em vários lugares.

Não é apenas a sua segurança que está em risco, é dos seus usuários. Você é responsável pela segurança dos seus usuários.

Abordamos mais um tópico sobre gerenciamento de senhas. E aqui novamente vale lembrar Uma autenticação feita por amadores, é uma autenticação amadora.
(Parafraseando a frase Amateurs Produce Amateur Cryptography)

Deixe seus comentários e feedbacks!

Referências

• Fast NTLM hash cracking with rainbow tables and RainbowCrack for GPU
• How Rainbow Tables work
• List of Rainbow Tables
• What are rainbow tables?
• Salted Password Hashing - Doing it Right
• Understanding Rainbow Tables