O que é um ataque de rainbow table e por que ele quase não funciona mais?

Illustration of a table icon with a small rainbow badge on a blue gradient background with wave patterns, symbolizing a rainbow table attack.

Sumário

Compartilhe este artigo:

Em resumo

Um ataque de rainbow table funciona comparando o hash de uma senha roubada com uma tabela de consulta pré-construída contendo pares conhecidos de hash e senha. O ataque perde completamente a eficácia quando a senha é armazenada com um salt, uma prática que hoje é padrão.

O salt adiciona um valor aleatório à senha antes que ela seja transformada em hash. Como cada senha recebe um valor aleatório exclusivo, duas senhas idênticas geram hashes armazenados completamente diferentes.

Essa simples mudança é o principal motivo pelo qual esse tipo de ataque passou de uma ameaça séria a uma técnica praticamente obsoleta. Para uma proteção completa da conta, o pacote de ferramentas do Mailfence combina criptografia com configurações de segurança robustas desde o momento em que você cria sua caixa de entrada.

O termo “ataque de rainbow table” aparece em quase toda lista de métodos de quebra de senhas. O nome parece intimidador, e por muito tempo foi mesmo.

O que mudou? Uma defesa simples, conhecida como salting, eliminou grande parte da eficácia desse tipo de ataque. A técnica não desapareceu completamente, porém. Ela ainda pode funcionar contra sistemas desatualizados e senhas reutilizadas.

Para proteger suas contas de forma completa, o pacote de ferramentas do Mailfence combina criptografia com configurações de segurança robustas desde o momento em que você cria sua caixa de entrada.

O que é um ataque de rainbow table?

Um ataque de rainbow table recupera senhas comparando hashes roubados com uma grande tabela pré-computada que associa hashes às senhas originais em texto simples. Em vez de tentar adivinhar a senha em tempo real, o invasor faz uma consulta direta.

Qualquer serviço competente armazena sua senha como um hash – uma impressão digital de tamanho fixo produzida por uma função de mão única. A senha original não é armazenada.

A vulnerabilidade surge porque senhas idênticas sempre geram hashes idênticos. Uma rainbow table explora justamente essa consistência, transformando um único arquivo preparado em uma ferramenta capaz de quebrar milhares de hashes roubados de uma só vez.

Essa eficiência fez dos ataques de rainbow table um atalho preferido para quebrar grandes conjuntos de senhas vazadas.

Por que este tipo de ataque é chamado de rainbow table?

O nome descreve o que acontece dentro da tabela, e não sua aparência. Cada tabela é construída a partir de cadeias de cálculos. Cada cadeia alterna entre duas operações: uma função hash, que transforma uma senha em uma sequência de caracteres de tamanho fixo, e uma função de redução.

Uma função de redução transforma um hash em uma nova senha candidata. Ela não reverte o hash nem descriptografa nada. Sua função é simplesmente gerar o próximo elo da cadeia.

Repetir essa alternância dezenas de vezes permite que uma única cadeia cubra um grande conjunto de senhas candidatas sem precisar armazenar cada uma delas separadamente. Apenas os valores inicial e final de cada cadeia são mantidos, reduzindo drasticamente o espaço de armazenamento necessário.

Nas versões mais sofisticadas, a própria função de redução muda a cada etapa. Essa variação evita que diferentes cadeias colidam entre si e deu origem ao nome colorido da técnica.

Como funciona um ataque de senha com rainbow table?

Cinco etapas resumem como funciona um ataque de senha com rainbow table:

  1. Obtenão dos hashes: O invasor obtém hashes de senhas, geralmente por meio de uma vulnerabilidade de software, de um banco de dados comprometido ou de um código malicioso
  2. Identificação do algoritmo: Ele seleciona ou gera uma rainbow table criada especificamente para o algoritmo de hash usado pelo sistema-alvo
  3. Processamento dos hashes pelas cadeias: Cada hash roubado passa pela mesma sequência de funções de redução usada para criar a tabela
  4. Identificação da correspondência: Quando um hash chega a um ponto final de uma cadeia conhecida, o invasor reproduz essa cadeia desde o início e recupera a senha original
  5. Reutilização da senha em outros serviços: Primeiro, ele testa a senha na conta comprometida. Depois, tenta usá-la em outros serviços, já que é a reutilização de senhas que pode causar os maiores danos

Rainbow table vs dictionary attack vs brute force

Um ataque de rainbow table faz parte de uma família maior de técnicas de quebra de senhas, que também inclui credential stuffing e password spraying.

💡 Em termos simples: o password spraying usa uma senha comum e a testa em um grande número de contas, em vez de testar várias senhas em uma única conta.

O que diferencia esses métodos é o momento em que os cálculos são feitos: alguns realizam todo o processamento em tempo real, enquanto outros dependem de uma preparação concluída muito antes do ataque começar. O brute force testa sistematicamente todas as combinações possíveis de caracteres até encontrar a senha correta.

CritérioRainbow tableBrute forceDictionary
Recurso principalTabela de consulta pré-construídaPotência de computação bruta (CPU/GPU)Listas de senhas comuns
PreparaçãoIntensaNenhumLeve
Velocidade durante o ataqueMuito rápida (consulta direta)LentaRápida contra padrões comuns
Funciona com hashes com saltNãoSimSim

Essa última linha explica tudo. Assim que o salt é aplicado, toda a tabela pré-construída se torna inútil.

Os ataques de rainbow table ainda são uma ameaça?

Contra sistemas modernos, quase nunca. Contra sistemas mais antigos, sem dúvida.

Formatos sem salt, como NTLM e LM, ainda existem em infraestruturas legadas. Muitos dispositivos conectados também chegam ao mercado com senhas padrão fracas. Ambos continuam sendo alvos fáceis para esse tipo de ataque.

O vazamento do LinkedIn em 2012 é um exemplo clássico. As senhas foram armazenadas com SHA-1 e sem salt, expondo cerca de 6,5 milhões de hashes. Uma parte significativa deles foi quebrada em poucos dias.

Quatro anos depois, a verdadeira dimensão do incidente ficou clara: cerca de 117 milhões de contas haviam sido afetadas pelo mesmo roubo ocorrido em 2012.

Credenciais roubadas continuam sendo um dos pontos de entrada mais confiáveis para invasores. O Data Breach Investigations Report, da Verizon, associou as credenciais comprometidas a cerca de um terço de todas as violações na última década. A reutilização de senhas é o que transforma um único hash quebrado em acesso a várias contas.

Gráfico de barras comparando 6,5 milhões de registros de senhas do LinkedIn expostos em 2012 com cerca de 117 milhões revelados em 2016 no mesmo vazamento.
O vazamento do LinkedIn em 2012 inicialmente parecia ter exposto 6,5 milhões de hashes de senhas. Em 2016, a verdadeira dimensão do mesmo incidente veio à tona: cerca de 117 milhões de contas foram afetadas, todas armazenadas como SHA-1 sem salt. Fonte: Krebs on Security / Have I Been Pwned, 2016.

Qual é a melhor defesa contra ataques de rainbow table?

O salting é a medida de proteção mais eficaz. Sem salting, uma rainbow table funciona exatamente como foi projetada para funcionar.

Funções específicas para armazenamento de senhas, como bcrypt ou Argon2, acrescentam uma camada extra de proteção. Diferentemente de funções hash de uso geral, como SHA-256, elas foram desenvolvidas especificamente para armazenar senhas: são deliberadamente lentas, exigem bastante memória e aplicam automaticamente um salt exclusivo para cada senha.

💡 Em termos simples: essas funções são projetadas para funcionar mais lentamente, tornando a quebra automatizada de senhas muito mais cara em termos de tempo, mesmo quando nenhuma tabela pré-computada é usada.

A reutilização de senhas é o que transforma um único hash quebrado em acesso a várias contas. Usar uma senha longa e exclusiva para cada conta não impede um ataque de rainbow table. Essa é uma defesa contra credential stuffing, mas limita os danos caso algum serviço seja comprometido. Saiba mais sobre hábitos relacionados a senhas.

A autenticação de dois fatores oferece uma camada adicional de proteção, bloqueando o acesso mesmo que uma senha seja recuperada.

A autenticação de dois fatores oferece uma camada adicional de proteção, reduzindo significativamente o risco de invasão da conta mesmo que uma senha seja recuperada.

Como o Mailfence protege sua conta contra ataques a senhas

O Mailfence usa algoritmos modernos com salt para gerar o hash de todas as senhas armazenadas.

As senhas das contas são armazenadas usando bcrypt, uma função de hash desenvolvida especificamente para senhas. O bcrypt gera automaticamente um salt aleatório e exclusivo para cada senha e o incorpora ao hash armazenado. Assim, um banco de dados roubado não terá duas entradas idênticas e as rainbow tables pré-construídas não terão com o que fazer correspondência.

As conexões pelo navegador são protegidas com SSL/TLS.

A autenticação de dois fatores (2FA) está disponível gratuitamente para todas as contas. Você pode ativá-la usando qualquer aplicativo autenticador compatível com TOTP e gerar códigos de backup para recuperar o acesso à conta. Embora nenhum método de 2FA elimine completamente os riscos – códigos TOTP podem, em princípio, ser obtidos por meio de phishing –, ele reduz significativamente o risco de acesso não autorizado, mesmo quando uma senha é comprometida.

Para acesso externo via SMTP, IMAP, POP, EAS, xDAV e XMPP, use senhas separadas e específicas para cada serviço, que podem ser revogadas individualmente. Desative também qualquer serviço de que você não precise. Isso reduz a superfície de ataque da conta sem afetar suas credenciais principais de acesso.

Uma série de configurações de segurança da conta permite reforçar ainda mais suas defesas no dia a dia.

“A melhor defesa contra os ataques de ontem raramente é algo extraordinário, mas sim disciplina. Cuidamos da parte mais difícil do nosso lado, armazenando todas as senhas com hashing moderno e salt, e oferecemos ferramentas simples, como a autenticação de dois fatores, para ajudar as pessoas a fechar essa lacuna do lado delas.” – Patrick De Schutter, cofundador da Mailfence

Principais conclusões

  • Uma rainbow table recupera senhas consultando seus hashes em uma tabela pré-construída, sem precisar fazer cálculos em tempo real
  • O salting elimina completamente a eficácia desse método, sendo o principal motivo pelo qual esse tipo de ataque perdeu força
  • Sistemas legados, hashes sem salt e dispositivos conectados com segurança insuficiente continuam vulneráveis
  • Uma senha forte e exclusiva, combinada com a autenticação de dois fatores, reduz significativamente o risco no nível da conta

Considerações finais sobre ataques de rainbow table

O ataque de rainbow table já foi considerado uma das técnicas mais perigosas de quebra de senhas. O salting e as funções hash modernas reduziram grande parte de sua eficácia, e hoje ele persiste principalmente em ambientes desatualizados ou configurados de forma inadequada.

Uma senha forte e exclusiva, combinada com a autenticação de dois fatores, continua sendo sua linha de defesa mais confiável.

Receba as últimas novidades sobre privacidade no seu e-mail

Inscreva-se na Newsletter da Mailfence.

Perguntas frequentes sobre ataques de rainbow table

Como os invasores descobrem qual algoritmo de hash foi usado?

Os hashes seguem padrões reconhecíveis de comprimento e formato. MD5, SHA-1 e NTLM, por exemplo, produzem assinaturas distintas. Depois de identificar o algoritmo, o invasor obtém a rainbow table correspondente.

As rainbow tables conseguem quebrar senhas longas ou complexas?

Na prática, não. O tamanho da tabela cresce exponencialmente conforme aumentam o comprimento da senha e a variedade de caracteres. Os invasores se concentram em senhas curtas e previsíveis, porque senhas longas e aleatórias ficam muito além do alcance viável de qualquer tabela.

As rainbow tables funcionam contra algoritmos modernos, como SHA-256?

Somente quando não há salt e, mesmo assim, isso raramente é viável na prática. O SHA-256 produz um número tão grande de possíveis resultados que criar uma tabela completa não é viável. O armazenamento de hashes SHA-256 com salt é, na prática, imune a esse tipo de ataque.

As rainbow tables são mais rápidas do que o brute force com GPU?

Quando o hash não tem salt e o algoritmo é rápido, sim. Na maioria das condições atuais, porém, o brute force com GPU é mais rápido. Ainda assim, uma tabela pré-construída pode fornecer resultados instantâneos para senhas comuns.

A 2FA impede um ataque de rainbow table?

Ela não impede que o hash seja quebrado, mas torna o resultado muito menos útil. Mesmo com sua senha em mãos, o invasor ainda precisaria do segundo fator, o que reduz significativamente o risco de invasão da conta. A 2FA baseada em TOTP pode, em princípio, ser alvo de phishing, portanto deve ser tratada como uma proteção forte, e não como uma proteção absoluta. O Mailfence oferece esse recurso gratuitamente, e ele funciona com qualquer aplicativo autenticador compatível com TOTP.

É possível detectar um ataque de rainbow table?

Normalmente, não enquanto ele está acontecendo. A quebra ocorre offline, sem conexão com seus sistemas. Você só poderá perceber a atividade quando o invasor tentar usar as senhas recuperadas para acessar contas ativas.

Recupere sua privacidade de e-mail.
Crie seu e-mail gratuito e seguro hoje.
Foto de Nihad

Nihad

Nihad é estratega de conteúdos na área da cibersegurança e proteção de dados e conta com quase uma década de experiência no desenvolvimento de estratégias editoriais e campanhas de marketing para empresas líderes no setor das VPN e da cibersegurança no mercado francês. Ela redige e localiza conteúdos que ajudam os leitores a orientarem-se nas áreas da segurança digital, proteção de dados online e novas tecnologias. Para além da criação de conteúdos, colabora em iniciativas relacionadas com a cibersegurança e a conformidade e presta apoio em áreas como as verificações KYC e AML.

Recomendado para você