Hash e criptografia? O que é um valor hash

Hashing vs. Encryption

Há um equívoco comum de que hash e criptografia são a mesma coisa. Eles não são. O hash é irreversível. Tomemos o exemplo a seguir:

$ echo-n Password123 | md5sum
42f749ade7f9e195bf475f37a44cafcb-

Passamos a string "Password123" para o algoritmo MD5 (algo), que realiza operações matemáticas e retorna o hash codificado hexadecimal gerado. A única maneira de obter o mesmo valor de saída hash é inserir algo em bruto. Há um conflito, mas podemos discutir isso mais tarde.

A saída da maioria dos algoritmos de hash é uma cadeia binária de comprimento fixo codificada hexadecimalmente. Outros, como este exemplo, usam uma cadeia codificada base64 como saída. Observe que o comprimento é sempre o mesmo:

{SHA} uNF8eZRJ8jmr8WTjyocRJPVpe7w =
{SHA} lqdu/Zr6o2dgIER8Up1/7lcUtgw =
{SHA} qYUOwLMlDEuukA5HCT4LR1kQzco =
{SHA} MXZBCpyWJ7TTs1w2kgGJslwNwTg =
{SHA} 2sAPLaUh9Mz0bI + XxKEg7qyABe8=

TL; Dr.

A criptografia é reversível e o hash não é

Não quero falar muito sobre criptografia (porque essas coisas são para livros), mas é importante ser capaz de distinguir entre uma string hash e uma string criptografada. A criptografia geralmente preenche uma cadeia de caracteres que atenda a um comprimento específico antes que a criptografia ocorra. Ele também requer uma chave (ou senha) para ser descriptografado. Se você estiver usando uma senha criptografada, a string mudará de acordo com o comprimento da entrada. Se você ver um monte de senhas de texto cifrado, cujo comprimento varia, você pode estar lidando com criptografia em vez de hash. AES-256-CBC Exemplo de criptografia de strings e texto simples associado (com a chave "ASDF"):

 foobar                           |   U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = 
foobarfoobar               |   U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = 
foobarfoobarfoobar   |   U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + ldatuqv2xexeaeoww0xg/EXJUe9aSUz 

$   cat   encrypted_passwords 
U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = 
U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = 
U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz 

$   para   i   em   `cat   encrypted_passwords`;   do   echo   $i   |   openssl   enc   -base64   -d   -aes-256-cbc   -pass   pass:asdf;   echo;   feito 
foobar 
foobarfoobar 
foobarfoobarfoobar 

Agora você pode pensar: você pode estar certo. No entanto, o fato de que o material crítico deve estar acessível ao sistema significa que, essencialmente, uma senha mestre de texto simples está localizada em algum lugar-seja como uma chave RSA ou uma senha em um arquivo, incorporada em um banco de dados, codificada em um aplicativo ou uma senha em algum lugar na memória. pfft, ninguém ' vai usar asdf como a chave para criptografar as senhas de seus usuários '

Usando a mesma string de MD5:

 foobar                           |   3858f62230ac3c915f300c664312c63f 
foobarfoobar               |   59faa421729e846dd800dce59943bfc0 
foobarfoobarfoobar   |   1352aadab322d1a033c27964be0965db 

A senha hash está longe de ser perfeita, na verdade é um pouco ruim, mas é pior que a criptografia por causa do que tenta alcançar. Os usuários selecionam o requisito mínimo absoluto com mais frequência do que not e podem usá-lo em vários sites. Muitos "hacks" são, na verdade, nada mais do que ataques de reutilização de credenciais. Se o compromisso inicial é o uso de criptografia, então o único esforço que o atacante deve fazer é encontrar a chave para descriptografar todas as senhas. Para os hash, eles precisam pelo menos fazer um esforço para quebrá-los. Quando usado com algoritmos modernos como sha512crypt, bcrypt, scrypt ou argon2, os valores de hash podem exigir um grande esforço para quebrar.

Marinado

Adicionar sal é adicionar uma string à senha antes do hash. O sal de cada hash deve ser exclusivo e geralmente selecionado aleatoriamente, pois o ponto é fazer com que o mesmo hash de texto claro "senha" tenha um valor diferente cada vez. Isso dificulta a vida dos quebradores de senhas, porque para verificar a palavra "senha" para cada um dos 1.000 usuários, cada usuário tem um sal único, e eles têm que fazer isso 1.000 vezes-uma vez por usuário/sal. Isso também significa que eles não podem usar dicionários pré-compilados ou tabelas arco-íris de forma eficiente (geralmente...), porque eles exigem um personalizado por sal.

Os sites às vezes estragam isso e usam sal genérico para todos os usuários; Isso vai contra o propósito.

Aqui está o hash SHA1 com sal:

 b353977827f67a4ae0318f3a9447fae1c13d9d90:b8d18ca 
|___________________________________________| 
                                    hash                                     |     sal 
                                        | 
                                                                        separador 

O texto claro deste hash é "senha". Seu valor de sal é "b8d18ca" e usa SHA1 ($salt.$pass) na API. Isso significa que o algoritmo obtém o texto claro da senha, gera o sal e o adiciona na frente do texto claro. Quando um site ou aplicativo tenta verificar sua senha no futuro, ele toma sua senha em texto claro como entrada, lê o valor salt no Hash armazenado, adiciona-o à frente da senha que você escolheu e compara o Hash gerado com o Hash armazenado. Se você não souber que parte dele é sal, o hash produzirá o seguinte texto simples:

b8d18capassword

Como o algoritmo faz a entrada de texto simples, sal e o hash gerado podem permanecer transparentes para o usuário. No momento do cracking, se o algoritmo é sal, precisamos conhecer o sal para que possamos fornecê-lo ao gerar o candidato Plain Text.

Se implementado corretamente, a salinização pode tornar a rachadura mais demorada. Com sal aleatório, você força o Cracker a perder tempo tentando quebrar valores de hash que o sal não corresponde. Isso completa aproximadamente o esforço necessário device_speed/number_of_salts, porque precisamos gerar um candidato para cada sal. Se o sal é estático, então as operações matemáticas são as mesmas... speed_of_device/1. Outra maneira de ver isso:

 nosso   GTX   980   cracks   SHA1 ($salt.$pass)   em   3576,8   MH/s   ou   3,5   bilhões   candidatos   por   segundo 
Nossa   hashlist   contém   1000   exclusivos   sais 

3.500.000.000   /   1000   =   3.500.000   candidatos   por   segundo 

Isso é três ordens de magnitude mais lento, com uma perda de 99,9%. Com sal estático, parece assim:

 Our   GTX   980   cracks   SHA1 ($salt.$pass)   at   3576,8   MH/s   ou   3,5   bilhões   candidatos   por   segundo 
Nossa   hashlist   contém   1   exclusivo   sal 
               
3.500.000.000   /   1   =   3.500.000.000   candidatos   por   segundo 

Se isso não faz sentido, continue lendo, teremos um gráfico bonito mais tarde...

Iteração

Outra melhoria comum em comparação com simplesmente "hash this plaintext" é que "hash this plaintext, then hash that result, then hash that result" é repetido milhares de vezes. Isso permite que o programa de quebra de senha tenha que fazer milhares de operações ao tentar uma única senha de candidato. Isso é chamado de iteração, loop ou custo variável. Alguns algoritmos de hash de senha usam rodadas de iteração codificadas; Outros Git. torná-lo configurável em parte do próprio Hash. Por exemplo, md5crypt () usa MD5, incluindo sal, e loop exatamente 1000 vezes. sha512crypt () usa sha512, inclui um sal e cicla um número configuravel de vezes (padrão é 5.000).

As iterações afetam principalmente o custo do ciclo de cálculo do algoritmo de hash, não seu uso de memória ou outros fatores. Esses também são ataques importantes ao projetar otimizados para resistir a certos tipos de tipos de hash, mas isso é muito erva para ser discutido aqui.

O efeito do tipo de hash na velocidade de crack

Vamos dar uma olhada em alguns exemplos para demonstrar o efeito da escolha do algoritmo de hash, seja salgado, usando várias iterações, etc. Suponha que um atacante colete 1.000 hash de usuários de um site infectado, e eles só querem realizar um simples ataque, testando cada hash de senha-143 milhões de senhas candidatas.

O tipo de hash usado pelo site infectado terá um enorme impacto no tempo necessário para o atacante passar pelo ataque. Aqui está um gráfico (relativo, aproximadamente) de quantos segundos levam para completar esse ataque, dependendo do tipo de hash usado, onde a placa gráfica padrão:

Bem, isso não adianta! Os tipos de hash mais fortes são muito mais lentos, mas os tipos mais rápidos são simplesmente esmagados até nada. Vamos tentar novamente a mesma escala de dados usando o tempo logarítmico do eixo X. À medida que as barras se movem da esquerda para a direita, elas vão aumentar a potência de 10:

Então alguns pontos importantes são: uma rodada única é mais fácil do que várias e sem sal do que com sal quando você quer quebrar algum hash de senha. Pelo contrário, quando determinadas empresas ou sites anunciam uma violação de dados contendo dados do usuário, a) a senha é preferível ter sido hash e não apenas texto simples; b) Eles são de preferência salgados e não apenas hash; c) É melhor que eles tenham usado várias rodadas poderosas de hash salgadas o tempo todo, e não apenas rodadas únicas.

Identificar o tipo de hash

Antes de tentar quebrar um determinado hash de senha, cabe ao cracker descobrir qual algoritmo de hash é usado para implementá-lo. Identificar tipos de hash é geralmente simples, mas nem sempre. Os Crackers geralmente fazem palpites fundamentados com base em pistas, como comprimento e formato do hash. No final das contas, a única maneira de ter certeza de que o tipo de hash está correto é se o hash está quebrado.

Alguns excelentes recursos para esta tarefa estão disponíveis aqui e aqui, e ambos mostram como os valores de hash comuns são.

O pacote "hash-identifier" (disponível aqui) está disponível no Kali Linux para ajudar a identificar tipos de hash desconhecidos.

Colisão

Um colisão ocorre quando duas entradas diferentes resultam na mesma saída hash. É ruim (obviamente). Para senhas, isso pode significar que eu provavelmente não quebrei sua senha real, mas como encontrei uma entrada que produz o mesmo valor de hash, posso usar o valor de texto simples para enganar o sistema para pensar que a senha é legítima.

O Microsoft Office usa um algoritmo em sua proteção de documentos que tem sido propenso a conflitos ao longo dos anos. Não é incomum encontrar vários conflitos para um único hash, todos desbloqueando o documento.

Assim que um conflito é encontrado, o algoritmo é realmente corrompido. Se acontecer uma vez, é estatisticamente provável que aconteça novamente. A única coisa que nos impede é o tempo e a capacidade de processamento. À medida que os algoritmos se tornam mais robustos, é necessário mais capacidade e tempo para gerar algoritmos candidatos e comparar as saídas de hash para pesquisá-los. Como resultado, os designers estão se tornando cada vez mais bons na criação de algoritmos menos propensos a conflitos.