Fechamos o Bloco VII com uma técnica engenhosa que ilumina, por contraste, por que as defesas modernas de senha são projetadas como são: as rainbow tables. Entendê-las completa sua compreensão do cracking e amarra num quadro coerente todas as defesas de autenticação espalhadas pelo curso. Esta aula é mais conceitual e serve de síntese: ao final, você terá o mapa completo do ataque e da defesa de senhas.

Pré-calcular em vez de calcular na hora

Comece pelo problema que as rainbow tables resolvem para o atacante. No cracking offline comum (aula Cracking offline com John e Hashcat: quebrando hashes em escala), para cada hash-alvo, você calcula o hash de cada candidata em tempo real — o que consome poder computacional a cada tentativa. Alguém percebeu: e se eu pré-calcular os hashes de milhões de senhas uma vez, guardar numa tabela gigante, e depois apenas consultar essa tabela para cada hash-alvo? Trocaria-se computação (lenta, repetida) por armazenamento e busca (rápida). Essa é a ideia básica das rainbow tables: tabelas pré-computadas que mapeiam senhas aos seus hashes, permitindo "reverter" um hash por simples consulta, sem recalcular nada. (A implementação real é mais sofisticada — usa cadeias de redução para economizar espaço, daí o "rainbow" —, mas o princípio é o trade-off entre tempo e espaço.)

Devastadoras contra hash desprotegido

Contra hashes desprotegidos, rainbow tables são devastadoras: um hash MD5 ou SHA-1 sem proteção pode ser "quebrado" em segundos por consulta a uma tabela pronta, e existem serviços online (bancos de dados de hashes conhecidos) que fazem exatamente isso — você cola o hash, ele devolve a senha, se estiver na base. É por isso que, na aula Hashes e assinaturas digitais: a impressão digital dos dados, dissemos que MD5 para senhas equivale quase a texto claro: para senhas comuns, o hash já foi pré-calculado por alguém, em algum lugar.

Por que o salt as destrói

E agora a beleza pedagógica desta aula: a defesa contra rainbow tables é uma que você já conhece, e aqui ela ganha seu sentido pleno — o salt. Lembre (aula Hashes e assinaturas digitais: a impressão digital dos dados): o salt é um valor aleatório único adicionado a cada senha antes de gerar o hash. Veja por que ele destrói as rainbow tables: a tabela pré-computada foi construída para senhas sem salt (ou com um salt específico). Se cada usuário tem um salt diferente e aleatório, a tabela pré-computada torna-se inútil — o atacante teria de gerar uma rainbow table nova para cada salt, o que anula completamente a vantagem de pré-computação (o esforço economizado some). Duas pessoas com a senha idêntica "123456" terão hashes totalmente diferentes por causa de salts distintos, então nenhuma tabela genérica as captura. O salt não torna a senha mais forte — torna o ataque em massa por pré-computação inviável. É uma defesa elegante e barata, e sua ausência é uma falha grave.

Isso permite montar a síntese defensiva completa das senhas, o mapa que quero que você leve do bloco inteiro, com cada defesa mirando um ataque específico:

O mapa das defesas por tipo de ataque

Contra ataques online (aula Brute force online com Hydra: atacando serviços vivos): account lockout / atrasos progressivos, rate limiting, CAPTCHA, e sobretudo MFA — que quebra a equação inteira, pois a senha sozinha deixa de bastar. Contra cracking offline (aula Cracking offline com John e Hashcat: quebrando hashes em escala): funções de hash lentas e adaptativas (bcrypt, scrypt, Argon2), que reduzem a velocidade do ataque a um filete. Contra rainbow tables (esta aula): salt único por senha, que inviabiliza a pré-computação. Contra todos eles, na base: senhas fortes, longas e únicas — que derrotam dicionário, resistem à força bruta, e não são reutilizadas entre serviços (a reutilização é fatal: um vazamento num serviço fraco compromete todos os outros via credential stuffing). E como camada final, gerenciadores de senha (que tornam viável ter senhas longas e únicas para tudo) e a migração para autenticação sem senha (passkeys, chaves de segurança) — a tendência que busca eliminar a senha como ponto único de falha.

Segurança de senha é defesa em profundidade

O ponto conceitual que encerra o bloco: a segurança de senhas é defesa em profundidade (o conceito da aula Por que o hacking ético existe e o que ele quer de você, agora concreto). Nenhuma defesa isolada basta — senhas fortes não impedem phishing, MFA pode ser contornado em casos específicos, hashing lento não ajuda se a senha é "123456". A robustez vem das camadas combinadas: senha forte + hashing lento e salgado + MFA + monitoramento + não reutilização. Cada camada mira um vetor, e juntas tornam o comprometimento de credenciais caro e difícil. Para o pentester, isso significa que, ao avaliar a postura de senhas de um cliente, você verifica todas as camadas, e reporta a ausência de cada uma como o que ela é — uma abertura específica na profundidade da defesa.

O ciclo completo dos ataques a senha

Com isto, encerramos os ataques a senhas. Você domina o ciclo completo: a teoria (online vs. offline, hashes, wordlists), o ataque online (Hydra, spraying), o offline (John, Hashcat, GPU), e o quadro defensivo integral (salt, hashing lento, MFA, senhas fortes). E note como o bloco se ancorou na enumeração anterior (as listas de usuários) e prepara a próxima: as credenciais que você obtiver aqui — por spraying, por cracking de hashes — são frequentemente a chave de entrada para a exploração e, principalmente, para a movimentação lateral. Daqui em diante abre o Bloco VIII — Exploração e Pós-Exploração, o coração do pentest, começando por entender o que é, de fato, um exploit.

Fontes e leituras recomendadas

Exercícios

  1. Qual problema do cracking comum as rainbow tables resolvem, e qual é o trade-off fundamental que elas exploram?

    ✓ Resposta:

    Resolvem o custo de recalcular hashes a cada tentativa: em vez de computar o hash de cada candidata em tempo real, pré-calculam-se os hashes uma vez e apenas se consulta a tabela. O trade-off fundamental é trocar computação (tempo) por armazenamento e busca (espaço).

  2. Por que MD5 e SHA-1 sem proteção são especialmente vulneráveis a rainbow tables?

    ✓ Resposta:

    Porque são hashes rápidos e, sem salt, produzem sempre o mesmo resultado para uma dada senha; assim, tabelas pré-computadas (ou bancos de hashes online) já contêm os hashes de senhas comuns, permitindo "revertê-los" por simples consulta em segundos.

  3. Explique detalhadamente por que o salt torna as rainbow tables inúteis. O salt torna a senha em si mais forte?

    ✓ Resposta:

    Porque a rainbow table é pré-computada para senhas sem salt (ou com um salt fixo); se cada senha recebe um salt aleatório e único, a mesma senha gera hashes diferentes, e a tabela genérica não corresponde a nenhum deles. O atacante precisaria recomputar uma tabela por salt, anulando a vantagem. O salt não fortalece a senha em si — inviabiliza o ataque em massa por pré-computação.

  4. Monte a síntese defensiva: associe uma defesa específica a cada tipo de ataque (online, offline, rainbow table).

    ✓ Resposta:

    Online → account lockout/rate limiting/CAPTCHA/MFA; offline → funções de hash lentas e adaptativas (bcrypt, scrypt, Argon2); rainbow tables → salt único por senha. Transversalmente, senhas fortes, longas e únicas defendem contra todos.

  5. Explique por que a segurança de senhas é um caso de "defesa em profundidade" e o que isso implica para a avaliação de um pentester.

    ✓ Resposta:

    Porque nenhuma defesa isolada basta — senha forte não impede phishing, MFA não cobre tudo, hashing lento não salva senha trivial. A robustez vem das camadas combinadas, cada uma mirando um vetor. Para o pentester, isso implica avaliar todas as camadas da postura de senhas do cliente e reportar a ausência de cada uma como uma abertura específica na profundidade da defesa.