Principais Padrões de Uso Indevido da Criptografia

O modo Código Eletrônico (ECB) criptografa cada bloco de forma independente, usando a mesma chave. Blocos de texto simples idênticos produzem blocos de texto cifrado idênticos. A demonstração clássica é o "pinguim do ECB": criptografar uma imagem de mapa de bits com ECB preserva a estrutura da imagem no nível dos blocos, tornando o contorno do pinguim claramente visível no texto cifrado. O modo ECB não oferece segurança semântica e nunca deve ser usado para nenhuma finalidade prática de criptografia.

Implementar primitivas criptográficas do zero é uma das práticas mais perigosas no desenvolvimento de software. A criptografia exige correção perfeita sob condições adversariais: um vazamento sutil de temporização, um erro de deslocamento de um no preenchimento ou uma compreensão equivocada dos requisitos de segurança podem criar vulnerabilidades exploráveis, indistinguíveis de um comportamento correto nos testes normais. Até criptógrafos especialistas cometem erros de implementação; desenvolvedores de aplicações devem usar exclusivamente bibliotecas bem auditadas.

O MD5 deixou de ser resistente a colisões em 2004; criar dois arquivos com o mesmo resumo MD5 é trivial do ponto de vista computacional. Ataques de colisão contra SHA-1 foram demonstrados na prática pelo ataque SHAttered do Google em 2017, que gerou dois arquivos PDF com o mesmo resumo SHA-1. Nenhum dos dois deve ser usado para qualquer finalidade de segurança: assinaturas digitais, integridade de conteúdo, armazenamento de senhas ou HMAC. Use SHA-256, SHA-3 ou BLAKE2 em implementações modernas.

Usar time() ou outros valores previsíveis para inicializar um gerador de números pseudoaleatórios é uma vulnerabilidade crítica quando a saída do PRNG é usada para fins de segurança. Um atacante que sabe aproximadamente quando uma chave foi gerada pode fazer força bruta no espaço de sementes (todos os possíveis carimbos de data e hora em uma janela pequena) para recuperar a chave. Um exemplo clássico: as primeiras versões do Netscape inicializavam a geração de chaves SSL com a hora e o ID do processo, ambos observáveis por um atacante na mesma máquina.

rand() em C, java.util.Random e o módulo random do Python usam geradores congruenciais lineares determinísticos ou o Mersenne Twister, projetados para qualidade estatística em simulações, não para segurança. Um atacante que observa uma quantidade suficiente de saídas desses geradores pode reconstruir seu estado interno e prever todas as saídas futuras. Para fins de segurança, use CSPRNGs fornecidos pelo OS: secrets.token_bytes() no Python, crypto.randomBytes() no Node.js ou /dev/urandom no Linux.

A criptografia sem autenticação oferece apenas confidencialidade, não integridade. Um atacante que não consegue ler o texto simples ainda pode modificar o texto cifrado, possivelmente provocando alterações previsíveis no texto simples (especialmente nos modos CTR ou CBC). Essa maleabilidade permite ataques: um atacante que intercepta uma transação bancária criptografada pode inverter bits para alterar o valor da transferência ou a conta de destino sem conhecer o texto simples. Use sempre criptografia autenticada (AEAD).

Codificar chaves de criptografia ou vetores de inicialização diretamente no código-fonte é uma vulnerabilidade crítica. O código-fonte costuma ser enviado para repositórios de controle de versão, às vezes públicos. Mesmo em repositórios privados, qualquer pessoa com acesso ao código tem a chave. Chaves codificadas diretamente fazem com que todas as instâncias usem a mesma chave, e a rotação da chave exige uma nova implantação. As chaves devem ser armazenadas em variáveis de ambiente, sistemas de gerenciamento de segredos (HashiCorp Vault, AWS Secrets Manager) ou módulos de segurança de hardware.

Usar o mesmo vetor de inicialização em várias criptografias com a mesma chave cria vulnerabilidades graves. No modo CTR, reutilizar o IV cria o mesmo fluxo de chaves, permitindo recuperar o texto simples por meio de XOR. No modo CBC, reutilizar o IV permite que um atacante detecte quando duas mensagens começam com os mesmos blocos de texto simples. No GCM, reutilizar o valor de uso único (IV) é catastrófico (consulte a lição sobre reutilização de valores de uso único). Gere um IV aleatório novo para cada operação de criptografia; acrescente-o ao texto cifrado para armazená-lo junto com o contexto de descriptografia.

Armazenar senhas usando MD5, SHA-256 ou qualquer outra função rápida de resumo criptográfico é inadequado. As GPUs modernas podem calcular bilhões de resumos SHA-256 por segundo, tornando trivialmente rápidos os ataques de força bruta fora de linha contra bancos de dados de resumos roubados. O armazenamento de senhas exige funções lentas e com uso intenso de memória, desenvolvidas especificamente para esse fim: bcrypt, scrypt ou Argon2id. Essas funções são projetadas para tornar a força bruta dispendiosa mesmo com hardware especializado, mantendo os ataques fora de linha computacionalmente inviáveis.

Desativar a validação de certificados SSL/TLS (definindo ssl.CERT_NONE no Python, passando -k ao curl ou definindo trustAllCerts=true no Android) elimina a proteção contra ataques de interceptação por intermediário. Um atacante pode apresentar qualquer certificado e interceptar todas as comunicações. Essa prática aparece em desenvolvimento para contornar erros de certificados autoassinados, mas frequentemente persiste em produção. Use sempre a validação adequada de certificados e corrija corretamente os problemas subjacentes dos certificados.

As funções criptográficas comunicam falhas por meio de valores de retorno ou exceções. Ignorá-las permite que a execução continue com um estado inválido: uma descriptografia que produziu lixo, uma verificação que falhou ou uma geração de chave que apresentou erro. Em APIs baseadas em C, como as do OpenSSL, ignorar valores de retorno é especialmente perigoso, pois o programa pode continuar usando memória não inicializada. Verifique sempre todos os valores de retorno das funções criptográficas e trate as falhas de forma segura.

Por que o modo ECB (Código Eletrônico) é considerado inseguro para criptografar dados?

Principais padrões de uso indevido a evitar: nunca use o modo ECB (vazamento de padrões de blocos), nunca implemente primitivas criptográficas por conta própria, rejeite MD5 e SHA-1 para fins de segurança, inicialize o PRNG com CSPRNG, não com time(), use CSPRNG para toda aleatoriedade sensível à segurança, sempre autentique os dados criptografados (AEAD), nunca codifique chaves ou IVs diretamente no código, gere um IV novo a cada criptografia, use Argon2id para senhas, não funções rápidas de resumo criptográfico, sempre valide certificados TLS e verifique todos os valores de retorno das funções criptográficas.