Segurança séria: MD5 considerado prejudicial - no valor de $ 600,000

Em uma fascinante deliberação legal proferida pelo regulador francês de proteção de dados CNIL (Comissão Nacional de Computação e Liberdades), a empresa de energia Électricité de France, ou EDF para abreviar, foi multa de 600,000 euros (cerca de US $ 600,000).

A declaração legal é, à maneira de tais coisas, bastante longa e (para não advogados, pelo menos) linguisticamente orotund, o que significa que você precisa de proficiência razoável em francês para entender todos os prós e contras do assunto, mas o caso geral se resume a quatro infrações.

Os três primeiros dizem respeito a interações gerais relacionadas a dados com clientes, abrangendo:

• Envio de e-mails de marketing comercial sem o devido consentimento.
• Coletando dados sem esclarecer o que ou por quê.
• Não lidar com solicitações de forma confiável quando os clientes pediram para ver seus dados, para ou excluí-los.

Mas é a última reclamação que despertou nosso interesse: Sur le manquement à l'obrigation d'assurer la securité des données.

Em inglês, isso pode ser traduzido livremente como falha em armazenar dados com segurança, e se relaciona muito especificamente com o manuseio inseguro de senhas.

MD5 considerado prejudicial

O regulador observou, entre outras coisas, que, apesar de alegar que estava trocando senhas usando um algoritmo de hash aceito, a EDF ainda tinha mais de 25,000 senhas de usuários “protegidas” com um único hash MD5 até julho de 2022.

Como você já deve ter ouvido muitas vezes no Naked Security, armazenar o hash criptográfico de uma senha significa que você pode validar uma senha quando ela é apresentada simplesmente recalculando seu hash e comparando-o com o hash da senha originalmente escolhida.

Se os hashes corresponderem, você poderá inferir com segurança que as senhas correspondem, sem precisar armazenar a senha real.

Quando apresentada, a senha só precisa ser mantida temporariamente na memória, podendo ser descartada assim que seu hash for calculado.

Contanto que o algoritmo de hash seja considerado criptograficamente seguro, ele não pode ser “executado ao contrário”, então você não pode trabalhar de trás para frente a partir do hash para revelar qualquer coisa sobre a própria senha. (Um hash desse tipo é conhecido no jargão como um função unidirecional.)

Da mesma forma, um algoritmo de hash decente evita que você comece com um hash conhecido e crie algum valor de entrada – qualquer entrada, não necessariamente a senha original – que produz o hash desejado.

Você precisaria tentar input após input até ter sorte, o que para hashes mesmo de 128 bits demoraria muito para ser um ataque praticável. (Um hash com a precaução de segurança de não permitir que você descubra várias entradas com a mesma saída é considerado resistente a colisão.)

Mas o MD5, como você provavelmente sabe, tem problemas significativos com colisões, assim como seu sucessor imediato SHA-1 (ambos os hashes foram lançados no início dos anos 1990).

Atualmente, nenhum dos dois algoritmos é recomendado para uso em qualquer lugar, por qualquer pessoa, para qualquer finalidade, visto que existem alternativas semelhantes, mas ainda seguras, que podem ser facilmente usadas para substituí-los, como SHA-256 e SHA-512:

Os hashes MD5 têm 128 bits, ou 16 bytes, de comprimento. SHA-256 e SHA-512 são 2x e 4x mais longos, respectivamente. Mas não é apenas esse tamanho extra de hash que os torna mais adequados. Sua principal vantagem sobre o MD5 é que eles não têm nenhum problema específico conhecido com colisões, portanto, sua segurança criptográfica não é considerada duvidosa como resultado.

Salgar e esticar

Resumindo, você não esperaria que nenhuma empresa, muito menos um gigante do setor de energia como a EDF, usasse o MD5 para qualquer finalidade criptográfica, muito menos para proteger senhas.

Pior ainda, porém, foi a falta de salga, que é onde um bloco de dados escolhido aleatoriamente para cada usuário é misturado com a senha antes que seu hash seja calculado.

O motivo de um sal é simples: ele garante que os valores de hash de senhas em potencial não possam ser calculados com antecedência e depois trazidos para ajudar em um ataque.

Sem salga, toda vez que algum usuário escolher a senha 123456, os bandidos sabem de antemão qual seria seu hash.

Mesmo que o usuário escolha uma senha mais adequada, como 34DF6467!Lqa9, você pode dizer com antecedência que seu hash MD5 será 7063a00e 41866d47 f6226e60 67986e91.

Se você tiver uma lista longa o suficiente de senhas pré-computadas ou de senhas parcialmente computadas (conhecidas esplendidamente no jargão como mesa arco-íris), você poderá recuperar a senha por meio da tabela em vez de tentar trilhões de combinações de senha até ter sorte.

Salgar significa que você precisaria de uma tabela arco-íris completa e pré-computada para cada usuário (a tabela é determinada pela combinação de salt + senha), e você não seria capaz de computar cada tabela arco-íris – uma tarefa que pode levar várias semanas e ocupar terabytes de espaço em disco – até que você recupere os salts de qualquer maneira,

Mas há mais coisas que você precisa fazer.

Mesmo se você incluir um sal, para que "dicionários de hash" pré-computados não possam ser usados, e você usar um algoritmo criptográfico confiável, como SHA-512, um cálculo de hash sozinho é suficientemente rápido para que os invasores que adquiriram um banco de dados de hashes possam ainda tente bilhões de senhas possíveis por segundo, ou até mais.

Então você deve usar o que é chamado alongamento também, onde você não apenas salga a senha inicial, mas também passa a entrada pelo algoritmo de hash milhares de vezes ou mais em um loop, tornando os ataques consideravelmente mais demorados para qualquer bandido que queira tentar.

Ao contrário da adição repetida, onde você pode usar uma única multiplicação como um atalho para substituir, digamos, o cálculo 5+5+5+5+5+5 por 6×5, não há atalhos para hashes repetidos. Para fazer o hash de uma entrada 1000 vezes, são necessárias 1000 “voltas” do identificador de cálculo criptográfico.

Não apenas um problema MD5

Ironicamente, parece que, embora a EDF tivesse apenas 25,800 senhas hash com MD5 e alegasse em sua defesa que estava usando principalmente SHA-512, ainda não estava sempre salgando ou estendendo os hashes armazenados.

O regulador relata que 11,200,000 senhas foram corretamente alteradas e com hash, mas, no entanto, 2,400,000 foram simplesmente criptografadas diretamente uma vez, seja com MD5 ou SHA-512.

Aparentemente, a EDF agora recuperou seu armazenamento de senhas, mas a empresa foi multada em 600,000 euros de qualquer maneira e permanecerá listada publicamente on-line na "etapa impertinente" da CNIL pelos próximos dois anos.

Não podemos ter certeza de qual multa teria sido aplicada se o julgamento envolvesse apenas hash pobre, e a EDF também não tivesse que responder pelas outras três infrações de proteção de dados listadas no início…

…mas isso mostra que más escolhas criptográficas podem custar-lhe dinheiro de várias maneiras!

O que fazer?

Armazene as senhas de seus clientes firmemente!

O custo computacional extra de salting-and-stretching pode ser escolhido de modo que os usuários individuais não sejam incomodados ao fazer login, mas os possíveis invasores têm suas velocidades de ataque aumentadas em várias ordens de magnitude.

Um ataque de recuperação de senha que pode levar uma semana para extrair 10% das senhas armazenadas como hashes one-shot simples levaria, em teoria, 200 anos (10,000 semanas) se você tornasse o custo de computação de cada senha de teste 10,000 vezes mais difícil .

Leia o nosso excelente artigo explicativo sobre este mesmo assunto:

Em suma, recomendamos o PBKDF2 algoritmo de “alongamento” com SHA-256 como seu hash principal, com um aleatório por usuário salt of 16 bytes (128 bits) ou mais.

Isso vai ao encontro das recomendações do último acórdão do CNIL.

O CNIL não oferece conselhos para o número de iterações PBKDF2, mas como você verá em nosso artigo, nosso conselho (outubro de 2022) é usar 200,000 or more. (Você pode aumentar regularmente o número de loops para acompanhar o aumento do poder de computação.)

Se você não quiser usar PBKDF2, sugerimos ler os algoritmos bcrypt, scrypt e Argon2 para ajudá-lo a fazer uma escolha sábia.

Não seja pego no passo impertinente criptográfico!

---