Quando é prejudicial ao hash

Prefácio
Este texto será um dos capítulos reescritos do manual sobre proteção de informações do Departamento de Engenharia de Rádio e Sistemas de Controle, bem como, a partir deste código de treinamento, o Departamento de Proteção de Informações do MIPT (GU). O tutorial completo está disponível no github (veja também versões preliminares ). Em Habrir, planejo apresentar novas peças "grandes", primeiro para coletar comentários e observações úteis e, segundo, para fornecer à comunidade mais material de visão geral sobre tópicos úteis e interessantes.

Uma função hash criptográfica confiável converte texto sem formatação em texto de um determinado comprimento. Isso garante "persistência": a dificuldade em restaurar o primeiro e o segundo protótipos. Ou, em linguagem clara sobre a primeira propriedade, a dificuldade de obter um texto desse tipo, cujo valor da função hash será igual ao especificado.

A complexidade da recuperação é entendida como o fato de que, para encontrar o primeiro protótipo [uma função hash criptográfica confiável], é necessário concluir uma média de pelo menos 2n1 operações de hash em que n - o número de bits na saída da função hash criptográfica. Adotando uma função hash moderna com um tamanho de saída grande (a partir de 256 bits), o desenvolvedor do sistema de informações tem certeza de que é impossível restaurar os dados originais a partir do valor da função hash. Na maioria das vezes ele está certo.

Mas há um conjunto importante de casos em que, apesar da confiabilidade da função hash, restaurar a imagem inversa ou mesmo o texto de origem não é um problema. Este é o caso quando o uso de uma função hash não faz sentido. É esse o caso quando o número de variantes do texto de origem é pesquisável .

Exemplo: número de telefone . Números de telefone diferentes com o prefixo "+7" e 10 dígitos são 1010 aprox.233 . Os dispositivos modernos que são otimizados para iterar sobre valores de hash são classificados em milhões de hashes por segundo. Isso significa que o cálculo dos valores das funções de hash para todos os números de telefone possíveis com um prefixo não passa de alguns segundos.

Exemplo: número do cartão de crédito (PAN, número do cartão de pagamento ). Muitas vezes, o número do cartão é mascarado, revelando os primeiros 4 (6) e / ou últimos 4 dígitos, enquanto oculta o restante. Existem 16 dígitos no cartão.É possível misturar os números dos cartões para ocultá-los do atacante? Não. Se um invasor recebeu 8 dígitos de 16 (os 4 primeiros e os 4 últimos), assim como o valor da função hash do número completo do cartão, ele pode recuperar o número completo em menos de um segundo. Para fazer isso, ele precisará resolver tudo 108 aprox.226 opções de número.

Um exemplo interessante com um endereço de email . Parece que, pelo valor de uma função hash confiável, é impossível restaurar o endereço original. O número de variantes diferentes de 8 letras latinas e 10 dígitos já fornece 368 aprox.241 opções para os nomes das caixas de correio sem levar em consideração os diferentes domínios dos serviços de email ( @mail.ru , @gmail.com , etc.). Se você usar outros caracteres permitidos, além de aumentar o endereço, há ainda mais opções. Mas ... Até 2006, o projeto Blue Frog (Blue Frog) funcionava, oferecendo aos seus usuários proteção anti-spam. Ele usou a notificação automática de provedores sobre spam enviado de seus servidores, o que forçou os anunciantes a se recusarem a enviar spam para pelo menos os endereços participantes do projeto. Para entender se a caixa pertence ou não ao participante, um arquivo foi distribuído com uma lista de valores da função de hash criptográfico do endereço da caixa de correio de cada membro.

Supunha-se que os spammers verificassem cada um de seus endereços para enviar anúncios nessa lista e excluir correspondências encontradas. No entanto, a presença de um arquivo com os valores da função hash permitiu que os atacantes fizessem exatamente o oposto: identificar os participantes do projeto e enviar fluxos reforçados de mensagens sem sentido para eles, a fim de recusar o uso do projeto Blue Frog. Algum tempo após esse ataque (assim como outros, incluindo ataques DDoS a servidores), o projeto parou de funcionar.

Como antes, o uso de qualquer salt que vem com o valor da função hash não afeta o tempo de enumeração (mas ainda protege contra ataques de dicionário).

Possíveis soluções para os casos descritos.

  1. Hash não os valores em si, mas a concatenação do valor original e algum segredo armazenado separadamente. Por exemplo, não na tabela do banco de dados (junto com os valores das funções de hash), mas na configuração do servidor de aplicativos. Com sucesso semelhante, em vez de usar hash, você pode usar a função de criptografia de bloco em alguma chave secreta.
  2. Use funções de hash que não são apenas confiáveis, mas também lentas na computação. Tanto para o criptoanalista quanto para o usuário legal. Um exemplo dessas funções é PBKDF2, bcrypt, scrypt, Argon2, para o qual, ao chamar uma função, indicamos adicionalmente o número de iterações de hash. No entanto, se aumentar o comprimento da saída da função hash em apenas um bit (de 256 ou 512) aumenta a complexidade do ataque do analista de criptografia por uma ordem binária (por um fator de dois), o aumento do número de iterações para a função de hash PBKDF2 dobrará a complexidade dos ataques por apenas dois vezes. Ou seja, obter um valor de hash mesmo por um usuário legal se torna caro em termos de recursos de computação e energia gasta.

Posfácio
O autor será grato por comentários factuais e outros sobre o texto.

Source: https://habr.com/ru/post/pt477416/


All Articles