O que é a tabela arco-íris, do banco de dados de hash?

A “tabela arco-íris” (rainbow table, em inglês) é uma técnica utilizada em criptoanálise e que está particularmente associada à quebra de senhas armazenadas utilizando funções de hash. Uma função de hash é um algoritmo que transforma dados em uma sequência de bits fixa, geralmente de tamanho fixo. Essa sequência é única para cada conjunto de dados de entrada e é chamada de “hash”.

As senhas, quando armazenadas em sistemas de computador, não devem ser armazenadas em texto simples por motivos de segurança. Em vez disso, os sistemas armazenam o hash das senhas. Isso significa que, quando um usuário tenta fazer login, a senha inserida é transformada em hash e comparada ao hash armazenado no sistema.

No entanto, uma tabela arco-íris é uma lista predefinida de hashes e as respectivas entradas de texto plano correspondentes. Os atacantes podem usar uma tabela arco-íris para realizar ataques de força bruta ou ataques de dicionário invertido. Eles calculam hashes para senhas comuns ou strings de texto simples usando a mesma função de hash utilizada pelo sistema alvo e, em seguida, comparam esses hashes com os hashes da tabela arco-íris. Se houver uma correspondência, a senha original correspondente àquele hash pode ser identificada.

Para mitigar esse tipo de ataque, são utilizadas técnicas como o “salting” (adicionar uma sequência aleatória de bytes ao final de cada senha antes de calcular o hash) e a utilização de funções de hash mais lentas e resistentes a ataques, como bcrypt ou Argon2. Essas técnicas tornam a criação de tabelas arco-íris muito mais difícil e demorada, tornando os ataques menos práticos.

Quantos salts é recomendado usar para as senhas de um banco de dados?

A quantidade de “salts” (sais, em português) recomendada para o armazenamento de senhas em um banco de dados varia dependendo das práticas de segurança específicas de cada sistema e das recomendações de segurança da informação. No entanto, geralmente é recomendado usar um salt único para cada senha.

Um “salt” é uma sequência de bits aleatória que é anexada à senha antes de ser passada pela função de hash. Isso ajuda a proteger contra ataques de dicionário e ataques de força bruta, tornando cada hash de senha única, mesmo que duas senhas sejam idênticas. Com um salt único para cada senha, mesmo senhas idênticas terão hashes diferentes, o que dificulta a descoberta das senhas originais através de tabelas arco-íris ou ataques similares.

Portanto, para cada senha armazenada em um banco de dados, recomenda-se utilizar um salt único. Isso significa que o número de salts necessários será igual ao número de senhas únicas armazenadas no banco de dados. É importante que esses salts sejam gerados de maneira verdadeiramente aleatória e tenham um tamanho adequado para garantir eficácia contra ataques. Em geral, os salts devem ter pelo menos 128 bits de comprimento para oferecer uma proteção adequada.

Então não é recomendado usar um salt único para todas as senhas?

Usar um salt único para todas as senhas não é uma prática recomendada. Cada senha deve ter seu próprio salt único. Isso é crucial para aumentar a segurança das senhas armazenadas em um banco de dados. Se um único salt for usado para todas as senhas, isso reduzirá significativamente a eficácia da proteção fornecida pelo salt.

Quando um salt único é usado para cada senha, mesmo que duas senhas sejam idênticas, os hashes resultantes serão diferentes devido à adição do salt único. Isso impede que atacantes usem tabelas arco-íris ou ataques de força bruta para descobrir as senhas originais, pois cada hash de senha será único.

Portanto, para garantir uma segurança adequada, é recomendado que cada senha tenha seu próprio salt único. Isso ajuda a mitigar diversos ataques de segurança e fortalece a proteção das senhas armazenadas em um banco de dados.

Um invasor consegue remover um salt do banco de dados?

Não, um invasor não pode “remover” um salt do banco de dados porque o salt é uma informação pública e geralmente não é sensível. Na verdade, o salt é comumente armazenado junto com a senha hash no banco de dados. Ele é usado para garantir que mesmo senhas comuns ou previsíveis gerem hashes únicos e, portanto, dificultar ataques de dicionário e tabelas arco-íris.

O propósito do salt não é ser secreto, mas sim único para cada senha e imprevisível, o que torna mais difícil para um invasor pré-calcular hashes para senhas comuns. Portanto, mesmo que um invasor obtenha acesso ao banco de dados, ele teria acesso tanto às senhas hash quanto aos salts. No entanto, sem conhecimento dos salts específicos utilizados para cada senha, seria extremamente difícil ou mesmo impraticável para o invasor realizar ataques eficazes de dicionário ou tabelas arco-íris.

Então quando um invasor tem acesso ao banco de dados, ele consegue ver quantos salts foram aplicados a cada senha?

Quando um invasor obtém acesso ao banco de dados, ele pode ver os hashes das senhas armazenadas, bem como os salts que foram aplicados a cada uma delas. Os salts geralmente são armazenados juntamente com os hashes das senhas, pois são necessários para verificar a autenticidade das senhas durante o processo de login.

No entanto, mesmo que o invasor tenha acesso aos salts, isso não compromete a segurança das senhas de forma significativa. O objetivo do salt não é ser secreto, mas sim único para cada senha e imprevisível, o que dificulta ataques de dicionário e tabelas arco-íris.

Mesmo que o invasor saiba quantos salts foram aplicados a cada senha, ele ainda enfrentará dificuldades significativas ao tentar quebrar as senhas, especialmente se forem usados salts longos e aleatórios. Portanto, o conhecimento dos salts pelo invasor não compromete substancialmente a segurança das senhas, desde que as práticas de segurança adequadas tenham sido seguidas.