Por que os sais tornam os ataques de dicionário 'impossíveis'?


85

Atualização: Observe que não estou perguntando o que é um sal, o que é uma tabela de arco-íris, o que é um ataque de dicionário ou qual é o propósito de um sal. Estou perguntando: Se você conhece os usuários salt e hash, não é muito fácil calcular sua senha?

Eu entendo o processo, e eu mesmo o implemento em alguns de meus projetos.

s =  random salt
storedPassword = sha1(password + s)

No banco de dados que você armazena:

username | hashed_password | salt

Cada implementação de sal que vi adiciona o sal no final da senha ou no início:

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

Portanto, um ataque de dicionário de um hacker que vale a pena (ha ha) simplesmente executaria cada palavra-chave contra os sais armazenados nas combinações comuns listadas acima.

Certamente, a implementação descrita acima simplesmente adiciona outra etapa para o hacker, sem realmente resolver o problema subjacente. Que alternativas existem para contornar esse problema, ou estou entendendo mal o problema?

A única coisa que posso pensar em fazer é ter um algoritmo de combinação secreto que liga o salt e a senha em um padrão aleatório, ou adiciona outros campos de usuário ao processo de hash, o que significa que o hacker teria que ter acesso ao banco de dados E código para amarrar para que um ataque de dicionário seja frutífero. (Atualização, conforme apontado nos comentários, é melhor presumir que o hacker tenha acesso a todas as suas informações, então provavelmente não é o melhor).

Deixe-me dar um exemplo de como proponho que um hacker hackearia um banco de dados do usuário com uma lista de senhas e hashes:

Dados de nosso banco de dados hackeado:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

Dicionário de senha comum:

   Common Password
   --------------
   letmein
   12345
   ...

Para cada registro de usuário, faça um loop nas senhas comuns e faça um hash para elas:

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

Espero que isso ilustre muito melhor o meu ponto.

Dadas 10.000 senhas comuns e 10.000 registros de usuário, precisaríamos calcular 100 milhões de hashes para descobrir o máximo possível de senhas de usuário. Pode demorar algumas horas, mas não é realmente um problema.

Atualização sobre a teoria do cracking

Assumiremos que somos um host corrompido, que tem acesso a um banco de dados de hashes e sais SHA1, junto com seu algoritmo para combiná-los. O banco de dados possui 10.000 registros de usuários.

Esse site afirma ser capaz de calcular 2.300.000.000 hashes SHA1 por segundo usando a GPU. (No mundo real, a situação provavelmente será mais lenta, mas por enquanto usaremos essa figura citada).

(((95 ^ 4) / 2300000000) / 2) * 10000 = 177 segundos

Dada uma gama completa de 95 caracteres ASCII imprimíveis, com um comprimento máximo de 4 caracteres, dividido pela taxa de cálculo (variável), dividido por 2 (assumindo que o tempo médio para descobrir a senha exigirá em média 50% das permutações) para 10.000 usuários levariam 177 segundos para descobrir as senhas de todos os usuários em que o comprimento fosse <= 4

Vamos ajustar um pouco para realismo.

(((36 ^ 7) / 1000000000) / 2) * 10000 = 2 dias

Supondo que não haja distinção entre maiúsculas e minúsculas, com um comprimento de senha <= 7, apenas caracteres alfanuméricos, levaria 4 dias para resolver para 10.000 registros de usuário, e reduzi pela metade a velocidade do algoritmo para refletir a sobrecarga e as circunstâncias não ideais.

É importante reconhecer que este é um ataque de força bruta linear, todos os cálculos são independentes um do outro, portanto é uma tarefa perfeita para vários sistemas resolverem. (IE fácil de configurar 2 computadores executando ataques de extremidades diferentes que ocupariam metade do tempo de execução).

Dado o caso de hash recursivo de uma senha 1.000 vezes para tornar esta tarefa mais cara computacionalmente:

(((36 ^ 7) / 1 000 000 000) / 2) * 1000 segundos = 10,8839117 horas

Isso representa um comprimento máximo de 7 caracteres alfanuméricos, a menos da metade da velocidade de execução do valor cotado para um usuário .

O hash recursivo 1.000 vezes bloqueia efetivamente um ataque geral, mas os ataques direcionados aos dados do usuário ainda são vulneráveis.


12
O objetivo do salting é evitar que você olhe para a senha com hash e veja que vários usuários têm o mesmo hash (e, portanto, a mesma senha). Sem sal, você poderia apenas usar o algoritmo de hash e gerar todos os hash possíveis e, em seguida, fazer uma pesquisa bruta por esse hash. Como o algoritmo nunca muda, ele o torna previsível para invasores, o sal apenas o torna muito mais difícil.
BeRecursive

25
Porque os biscoitos são como lesmas, e o sal seca as mucosas da pele e os mata.
TED de

6
@TED: Eu gosto de biscoitos salgados. Lesmas salgadas, nem tanto.
FrustratedWithFormsDesigner

3
@Tom - em seu exemplo de ataque. Se não houver sal, o invasor pode fazer "para cada senha comum, hash a senha. Isso corresponde a um ou mais usuários? Sim, eu tenho a senha deles" - o invasor é capaz de atacar todas as senhas "em paralelo" , sem nenhum custo extra.
Damien_The_Unbeliever

3
@Tom Gullen - você tem apenas metade da imagem. Sem o salt, um invasor não usaria o método que você demonstra na "Atualização 2". Ele simplesmente faria uma pesquisa em uma tabela e obteria a senha no tempo O (1) ou O (log n) (sendo n o número de senhas candidatas). O sal é o que impede isso e o força a usar a abordagem O (n) que você demonstra. Outra técnica (reforço de chave) pode fazer com que cada tentativa em seu loop demore um segundo inteiro, o que significa que levará 3 anos para realizar esses testes ... e com apenas 10k senhas, é provável que você decifre nenhuma senha nesse Tempo.
Erickson

Respostas:


31

Sim, você precisa de apenas 3 dias para sha1 (salt | senha). É por isso que bons algoritmos de armazenamento de senha usam hashing de 1000 iterações: você precisará de 8 anos.


3
+1, a resposta mais concisa e direta até o momento, eu não sabia que essa era uma opção.
Tom Gullen

Aparentemente, você nunca fez um benchmark de hash em seu sistema. Você pode fazer MUITOS MILHÕES de cálculos sha1 por segundos. 1.000 rodadas não fazem sentido para um invasor. Além disso, -1 porque sha1 é uma função hash quebrada.
rook

Aparentemente, estou usando nomes e números da pergunta. Se você já ouviu falar sobre tópicos e clareza ... ah, é Rook. Deixa pra lá.
blaze em

1
@Rook, 1.000 rodadas significa que levará 1.000 vezes mais tempo para a força bruta. Parece um bom recurso para mim.
Tom Gullen

se um invasor consegue adivinhar uma senha, é o mesmo para login (ou algo escapou para mim? lol)
khaled_webdev

62

Isso não impede os ataques de dicionário.

O que isso faz é impedir que alguém que consegue uma cópia do seu arquivo de senha use uma tabela arco - íris para descobrir quais são as senhas dos hashes.

Eventualmente, pode ser uma força bruta, entretanto. A resposta a essa parte é forçar seus usuários a não usar palavras do dicionário como senhas (requisitos mínimos de pelo menos um número ou caractere especial, por exemplo).

Atualizar :

Eu deveria ter mencionado isso antes, mas alguns (a maioria?) Sistemas de senha usam um sal diferente para cada senha, provavelmente armazenado com a própria senha. Isso torna uma única tabela de arco-íris inútil. É assim que a biblioteca crypt do UNIX funciona, e sistemas operacionais modernos como o UNIX ampliaram essa biblioteca com novos algoritmos de hash.

Eu sei que o suporte para SHA-256 e SHA-512 foram adicionados em versões mais recentes do GNU crypt.


17
+1 Salt evita que listas pré-computadas de hashes (rainbow tables) sejam úteis. O atacante deve começar tudo de novo.
Ian Boyd

2
No PHP, você pode usar as bibliotecas mcrypt ou bcrypt para uma criptografia melhor do que md5 ou sha1. Se você está preso com md5 ou sha1, deve 'esticar', onde você hash a senha 1000 vezes antes de chegar ao que está armazenado no banco de dados. Isso mantém a entropia igual, mas aumenta o tempo para calcular o hash.
Malfist

2
@Tom Gullen, que artigos você está lendo? Peritos autoproclamados ou artigos revisados ​​por pares em uma revista científica?
Malfist

7
E é o seu desenvolvedor comum que faz aquelas postagens de blog / ajuda sobre como escrever um sistema "seguro". A segurança não é algo que você pode pegar lateralmente, ela requer amplo conhecimento. É injusto? Provavelmente. É seguro? Até certo ponto. Existem razões pelas quais existem especialistas em segurança. Mas, novamente, nem tudo precisa ser tão seguro quanto Fort Knox. A melhor política aqui é usar um sistema pré-construído projetado por esses especialistas e modificá-lo para atender às suas necessidades.
Malfist

3
@Michael: Com um sal mais longo, você precisa pré-calcular todos os valores de sal possíveis, para que ele apareça na tabela do arco-íris. O ponto é que você não mantém o mesmo sal para todas as senhas, você o escolhe aleatoriamente para cada senha e o armazena no banco de dados próximo à senha armazenada com sal com hash. Portanto, um hacker precisaria de uma entrada na tabela rainbow para cada sal de valor grande possível, fazendo com que a tabela fosse muito grande para ser viável, que é o ponto.
Colin DeClue

31

Para ser mais preciso, um ataque de dicionário , ou seja, um ataque em que todas as palavras de uma lista exaustiva são tentadas, não fica "impossível", mas torna-se impraticável : cada pedaço de sal dobra a quantidade de armazenamento e computação necessária .

Isso é diferente de ataques de dicionário pré-computados, como ataques envolvendo tabelas de arco-íris em que não importa se o sal é secreto ou não.

Exemplo: Com um salt de 64 bits (ou seja, 8 bytes), você precisa verificar 2 64 combinações de senha adicionais em seu ataque de dicionário. Com um dicionário contendo 200.000 palavras, você terá que fazer

200.000 * 2 64 = 3,69 * 10 24

testes no pior caso - em vez de 200.000 testes sem sal.

Um benefício adicional do uso de salt é que um invasor não pode pré-computar os hashes de senha de seu dicionário. Simplesmente levaria muito tempo e / ou espaço.

Atualizar

Sua atualização presume que um invasor já conhece o salt (ou o roubou). Claro que esta é uma situação diferente. Ainda assim, não é possível para o invasor usar uma tabela de arco-íris pré-computada. O que importa muito aqui é a velocidade da função de hashing. Para tornar um ataque impraticável, a função de hashing precisa ser lenta. MD5 ou SHA não são bons candidatos aqui porque foram projetados para serem rápidos; melhores candidatos para algoritmos de hash são Blowfish ou algumas variações dele.

Atualização 2

Uma boa leitura sobre como proteger os hashes de senha em geral (indo muito além da pergunta original, mas ainda interessante):

Chega de tabelas do arco-íris: o que você precisa saber sobre esquemas de senha segura

Corolário do artigo: Use hashes salgados criados com bcrypt (baseado no Blowfish) ou Eksblowfish que permite usar um tempo de configuração configurável para tornar o hash lento.


4
@Tom Gullen - mesmo com políticas de senha fortes razoáveis, um dicionário de centenas de milhões ou alguns bilhões de candidatos provavelmente obterá alguns resultados, porque todas as senhas não são igualmente prováveis ​​(porque as pessoas usam mnemônicos, em vez de RNGs, para escolhê-las) . Um dicionário desse tamanho é pré-computável em sistemas de commodities se o sal não for usado. Se o salt for usado, o invasor terá que recomputar os hashes todas as vezes e, se iterações suficientes do hash forem realizadas, a taxa de ataque do invasor pode ser reduzida para algumas tentativas por segundo.
Erickson

3
-1 de mim: ser mantido em segredo não é totalmente o ponto dos sais. Você precisa deles acessíveis para verificar as senhas de qualquer maneira, portanto, qualquer tentativa de mantê-los em segredo provavelmente tornará o sistema mais vulnerável devido à complexidade adicional, em vez de realmente ter sucesso.
Michael Borgwardt

2
@ 0xA3: novamente: ser desconhecido para um invasor não é o ponto de vista . Sua máquina precisa acessá-lo de alguma forma, para que um invasor que invada a máquina também possa obtê-lo. Qualquer cenário em que o atacante não conhece o sal é uma pista falsa.
Michael Borgwardt

1
Acho que vale a pena mencionar que o artigo vinculado descreve incorretamente as tabelas arco-íris. O que ele descreve é ​​um simples anexo de dicionário. As tabelas do arco-íris são realmente bem diferentes (e um pouco mais complexas). Há uma explicação bastante decente de como as tabelas de arco-íris realmente funcionam em: kestas.kuliukas.com/RainbowTables
Jerry Coffin

3
-1 para "Claro que o sal precisa ser mantido em segredo". Se um invasor tiver acesso aos seus hashes de senha, ele terá seus sais também - o que você precisa são sais por usuário , não a segurança através da obscuridade de um sal "oculto".
snemarch

17

Um dicionário é uma estrutura onde os valores são indexados por chaves. No caso de um ataque de dicionário pré-calculado, cada chave é um hash e o valor correspondente é uma senha que resulta no hash. Com um dicionário pré-calculado em mãos, um invasor pode "instantaneamente" pesquisar uma senha que produzirá o hash necessário para fazer o login.

Com o salt, o espaço necessário para armazenar o dicionário cresce rapidamente ... tão rapidamente que tentar pré-computar um dicionário de senha logo se torna inútil.

Os melhores sais são escolhidos aleatoriamente de um gerador de números aleatórios criptográficos. Oito bytes é um tamanho prático e mais de 16 bytes não tem nenhum propósito.


O sal faz muito mais do que apenas "tornar o trabalho de um invasor mais irritante". Ele elimina toda uma classe de ataque - o uso de dicionários pré-computados.

Outro elemento é necessário para proteger completamente as senhas, que é o "reforço das chaves". Uma rodada de SHA-1 não é boa o suficiente: um algoritmo de hashing de senha segura deve ser muito lento em termos computacionais.

Muitas pessoas usam PBKDF2, uma função de derivação chave, que realimenta os resultados para a função hash milhares de vezes. O algoritmo "bcrypt" é semelhante, usando uma derivação de chave iterativa que é lenta.

Quando a operação de hashing é muito lenta, uma tabela pré-computada torna-se cada vez mais desejável para um invasor. Mas o sal adequado derrota essa abordagem.


Comentários

Abaixo estão os comentários que fiz sobre a questão.


Sem o salt, um invasor não usaria o método demonstrado na "Atualização 2". Ele simplesmente faria uma pesquisa em uma tabela pré-calculada e obteria a senha no tempo O (1) ou O (log n) (n sendo o número de senhas candidatas). O sal é o que impede isso e o força a usar a abordagem O (n) mostrada na "Atualização 2".

Uma vez reduzido a um ataque O (n), temos que considerar quanto tempo leva cada tentativa. O reforço de chave pode fazer com que cada tentativa no loop demore um segundo inteiro, o que significa que o tempo necessário para testar 10 mil senhas em 10 mil usuários vai se estender de 3 dias a 3 anos ... e com apenas 10 mil senhas, você provavelmente perderá senhas naquele tempo.

Você deve considerar que um invasor usará as ferramentas mais rápidas que puder, não o PHP, portanto, milhares de iterações, em vez de 100, seriam um bom parâmetro para reforço de chave. Deve levar uma grande fração de segundo para calcular o hash para uma única senha.

O reforço de chave é parte dos algoritmos de derivação de chave padrão PBKDF1 e PBKDF2, do PKCS # 5, que são ótimos algoritmos de ofuscação de senha (a "chave derivada" é o "hash").

Muitos usuários no StackOverflow referem-se a este artigo porque ele foi uma resposta à postagem de Jeff Atwood sobre os perigos das tabelas rainbow. Não é meu artigo favorito, mas discute esses conceitos com mais detalhes.


Claro que você assume que o invasor tem tudo: salt, hash, nome de usuário. Suponha que o invasor seja um funcionário corrupto da empresa de hospedagem que jogou a tabela do usuário no seu fansite myprettypony.com. Ele está tentando recuperar essas senhas porque vai se virar e ver se seus fãs de pôneis usaram a mesma senha em suas contas citibank.com.

Com um esquema de senha bem projetado, será impossível para esse cara recuperar qualquer senha.


1
Eu acho que por "ataque de dicionário", Tom se refere a experimentar senhas fracas conhecidas (ou seja, direto de um dicionário de linguagem humana), não tabelas de texto simples hash pré-computadas - é também nisso que penso quando leio "dicionário" em neste contexto.
Michael Borgwardt

@Michael Borgwardt: Concordo, @erickson se refere a ataques de dicionário pré-computados.
Dirk Vollmar

1
Salt interrompe ataques de dicionário pré-computados. O fortalecimento das teclas interrompe os ataques de dicionário. Ambos devem ser usados ​​juntos para autenticação de senha segura.
Erickson

Quero dizer tabelas simples em inglês, sim. A questão visa resolver o problema de como impedir um hacker de resolver todas as combinações possíveis de hashes para cada conta de usuário
Tom Gullen

7

O objetivo da salga é evitar a amortização do esforço do atacante.

Sem sal, uma única tabela de entradas de hash-senha pré-computadas (por exemplo, MD5 de todas as cadeias alfanuméricas de 5 caracteres, fácil de encontrar online) pode ser usada em todos os usuários em todos os bancos de dados do mundo.

Com um sal específico do site, o invasor precisa calcular a tabela sozinho e pode usá-la em todos os usuários do site.

Com um sal por usuário, o invasor precisa despender esse esforço para cada usuário separadamente.

Obviamente, isso não ajuda muito a proteger senhas realmente fracas direto de um dicionário, mas protege senhas razoavelmente fortes contra essa amortização.


1
Resposta curta e precisa - vale a pena acrescentar que sem sal ou com sal em todo o site, você pode identificar facilmente os usuários com a mesma senha e só precisará usar uma de força bruta. Com sais por usuário, você não pode fazer isso.
snemarch

6

Além disso - mais um ponto importante - usar um sal específico do USUÁRIO evita a detecção de dois usuários com a MESMA senha - seus hashes corresponderiam. É por isso que muitas vezes o hash é hash (salt + nome de usuário + senha)

Se você tentar manter o hash em segredo, o invasor também não poderá verificar os hashes.

Editar- apenas notei que o ponto principal foi feito em um comentário acima.


1
Você deve editar para especificar o salt por usuário; sites que usam um salt de todo o site ainda permitirão que você detecte senhas idênticas.
snemarch

@snemarch - Sim- muito obrigado por esta importante distinção!
Dominik Weber

5

Os sais são implementados para evitar ataques de arco-íris. Uma rainbow table é uma lista de hashes pré-calculados, o que torna a tradução de um hash em sua frase muito mais simples. Você precisa entender que o sal não é eficaz como uma prevenção moderna para quebrar uma senha, a menos que tenhamos um algoritmo de hash moderno.

Digamos que estejamos trabalhando com SHA1, aproveitando os exploits recentes descobertos com este algoritmo, e digamos que temos um computador rodando a 1.000.000 hashes / segundo, levaria 5,3 milhões de milhões de anos para encontrar uma colisão , então sim php pode trabalhar 300 por segundo, grande uau, realmente não importa. A razão de salmos é porque se alguém se preocupou em gerar todas as frases comuns do dicionário, (2 ^ 160 pessoas, bem-vindos aos exploits da era de 2007).

Então aqui está um banco de dados real, com 2 usuários que uso para fins de teste e administração.

RegistrationTime        UserName        UserPass    
1280185359.365591       briang      a50b63e927b3aebfc20cd783e0fc5321b0e5e8b5
1281546174.065087       test        5872548f2abfef8cb729cac14bc979462798d023

Na verdade, o esquema de sal é o seu sha1 (tempo de registro + nome de usuário). Vá em frente, diga-me minha senha, essas são senhas reais em produção. Você pode até sentar lá e ver uma lista de palavras em php. Enlouquecer.

Não sou louco, só sei que é seguro. Por diversão, a senha do teste é test. sha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023

Você precisaria gerar uma tabela de arco-íris inteira perpendida com 27662aee8eee1cb5ab4917b09bdba31d091ab732 apenas para este usuário. Isso significa que eu posso permitir que minhas senhas não sejam comprometidas por uma única tabela de arco-íris, o hacker precisa gerar uma tabela de arco-íris inteira para 27662aee8eee1cb5ab4917b09bdba31d091ab732 para teste e novamente f3f7735311217529f2e020468004a2aa5b3dee7f para briang. Pense nos 5,3 milhões de milhões de milhões de anos para todos os hashes. Pense no tamanho de armazenar apenas 2 ^ 80 hashes (isso é bem mais de 20 yottabytes ), isso não vai acontecer.

Não confunda o sal com um meio de fazer um hash algo que você não pode decodificar, é um meio de evitar que uma rainbow table traduza todas as suas senhas de usuário. É impossível neste nível de tecnologia.


Eu entendo o que é uma mesa arco-íris, mas você está perdendo o ponto da minha pergunta. Se você me forneceu seu algoritmo de sal, uma senha com hash e o sal, então sim, provavelmente poderia dizer qual era sua senha em alguns minutos.
Tom Gullen

Coloque seu dinheiro onde está sua boca?
Incógnito de

Claro, mas você acabou de me dizer qual é a senha no seu exemplo, me dê um salt, senha com hash e como você combina o salt + senha (não recursiva) e contanto que a senha <= 5 caracteres alfanuméricos minúsculos (sem espaço em branco / caracteres especiais) Eu direi o que há nesta caixa. Se você quiser que eu coloque dinheiro nisso como você sugere, diga-me, embora meu comentário de alguns minutos seja provavelmente uma subestimação grosseira, mas dentro de horas sim.
Tom Gullen

1
Talvez segundos, na verdade, consulte golubev.com/hashgpu.htm, que usa a GPU para calcular como "2300M / s SHA1 hashes por segundo". Com uma gama completa de 95 caracteres ASCII de 1 a 6 caracteres, podemos decifrá-lo em menos de 6 minutos. Se tivermos apenas caracteres alfanuméricos em minúsculas, até 8 caracteres de comprimento <25 minutos. Com um banco de dados de 10.000 registros de usuário, poderíamos encontrar todas as senhas ASCII completas de 4 caracteres em <200 segundos ((((95 ^ 4) / 2300000000) / 2) * 10000). (Mais sobrecarga do que o citado e as velocidades de GPU citadas são provavelmente situações ideais).
Tom Gullen

Sim, salting não impede que você seja capaz de usar força bruta para essa senha. Isso torna mais difícil para você gerar ((10 ^ 5) * (94 ^ 10)) = 10 ^ 24 se os usuários tiverem senhas de 10 caracteres, o que é muito mais difícil do que 10 ^ 19 sem hashes. Novamente, não é para dificultar a quebra de uma senha, é para inviabilizar a quebra de todas as senhas com uma tabela de arco-íris pré-processada. (e verifique minha matemática aqui, mas acredito que 10 ^ 25/2300000000/60/60/24/365/1000 = 137 869 ~ milinea para a senha de todos). Se quisermos senhas mais fortes, não as adicionamos, usamos coisas como troca de chaves Diffie-Hellman.
Incognito

3

A ideia por trás do ataque de dicionário é que você pegue um hash e encontre a senha, a partir da qual esse hash foi calculado, sem cálculo de hash. Agora faça o mesmo com a senha com sal - você não pode.

Não usar um salt torna a pesquisa de senha tão fácil quanto a pesquisa no banco de dados. Adicionar um salt faz com que o invasor execute o cálculo hash de todas as senhas possíveis (mesmo para anexar um dicionário, isso aumenta significativamente o tempo de ataque).


No cenário do OP, o invasor possui os sais do banco de dados e terá que tentar cada sal com cada entrada no "dicionário". ...Eu acho que.
FrustratedWithFormsDesigner

2

Em termos mais simples: sem sal, cada senha candidata precisa apenas ser hash uma vez para compará-la com cada usuário, em qualquer lugar no "universo conhecido" (coleção de bancos de dados comprometidos), cuja senha é hash através do mesmo algoritmo. Com o sal, se o número de possíveis valores de sal exceder substancialmente o número de usuários no "universo conhecido", cada senha candidata deve ser hash separadamente para cada usuário contra o qual será testada.


2

Colocar simplesmente sal não impede que um hash ataque (força bruta ou dicionário), apenas torna mais difícil; o invasor precisará encontrar o algoritmo de sal (que, se implementado corretamente, fará uso de mais iterações) ou força bruta no algoritmo, o que, a menos que seja muito simples, é quase impossível. A salga também descarta quase completamente a opção de pesquisas da tabela arco-íris ...


1

O sal faz a mesa do arco-íris ataques à muito mais difíceis, pois torna um hash de senha única muito mais difícil de quebrar. Imagine que você tenha uma senha horrível de apenas o número 1. Um ataque de rainbow table quebraria isso imediatamente.

Agora imagine que cada senha no banco de dados é salgada com um valor longo e aleatório de muitos caracteres aleatórios. Agora sua senha ruim de "1" está armazenada no banco de dados como um hash de 1 mais um monte de caracteres aleatórios (o sal), portanto, neste exemplo, a tabela de arco-íris precisa ter o hash para algo como: 1.

Então, supondo que seu salt seja algo seguro e aleatório, digamos ()% ISLDGHASKLU ( % #% #, a tabela de arco-íris do hacker precisaria ter uma entrada para 1 * ()% ISLDGHASKLU (*% #% #. Agora usando uma tabela de arco-íris até mesmo essa senha simples não é mais prática.


Por favor, consulte a atualização # 2, você simplesmente teria senhas brutas e calcularia todos os hashes em relação aos sais para cada registro de usuário.
Tom Gullen

2
Claro, Tom, eu concordo, mas o ponto é que o hacker tem que fazer aquele processo demorado e feio uma vez para cada senha se o salt for usado. Assim, o sal torna o uso de uma mesa arco-íris mais difícil.
Cory House

3
@Tom Gullen: gerar tabelas de arco-íris salgadas só é viável se sais em todo o site forem usados; o sal por usuário torna os ataques rainbow table praticamente inúteis.
snemarch
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.