Pergunta sobre hash, bcrypt, salt, encryption, passwords – Senhas de aplicativos da Web: bcrypt e SHA256 (e scrypt)

13

Com todas as discussões recentes (por exemplo, LinkedIn) de senhas, estou olhando para implementações de hash de senha. Depois de duas xícaras de café e uma manhã lendo eu não sou mais um criptógrafo do que quando eu comecei. E eu realmente não quero fingir que sou.

Questões Específicas

O uso de um ID de usuário único inteiro falha como um sal efetivo? (crypt () usa apenas 16 bits?)

Se eu simplesmente executar sha256 () em um hash repetidamente até que um segundo seja usado, isso derrota os ataques de força bruta?

Se eu tiver que fazer essas perguntas, devo usar o bcrypt?

Discussão / Explicação:

O objetivo é simplesmente se as senhas hash dos usuários vazaram:

não seria "fácil" de quebrar,quebrar uma senha não expõe outros usuários que usam a mesma senha).

O que eu li para o número 1 é que a computação hash deve ser cara - levando, digamos, um segundo ou dois para calcular e talvez exigir um bit ou memória (para impedir a descriptografia de hardware).

O bcrypt tem isso embutido, e o scrypt, se bem entendi, é mais preparado para o futuro e inclui um requisito mínimo de uso de memória.

Mas, é uma abordagem igualmente eficaz comer o tempo "refazendo" o resultado de sha256 () quantas vezes forem necessárias para gastar alguns segundos e, em seguida, armazenar a contagem final do loop com o hash para verificar posteriormente uma senha fornecida?

Para o nº 2, é importante usar um sal exclusivo para cada senha. O que não está claro é quão aleatório (ou grande) o sal deve ser. Se o objetivo é evitar que todos que usam "mypassword" como senha tenham o mesmo hash, não basta simplesmente fazer isso ?:

hash = sha256_hex( unique_user_id + user_supplied_password );

ou mesmo isso, embora eu não tenha certeza se me compra alguma coisa:

hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );

O único benefício que posso ver de usar o ID do usuário, além de eu sei que é único, é evitar ter que salvar o sal junto com o hash. Não é muito de uma vantagem. Existe um problema real em usar o ID de um usuário como o sal? Não cumpre o nº 2?

Suponho que, se alguém puder roubar as senhas com hash do meu usuário, devo assumir que elas podem obter o que quiserem, incluindo o código-fonte que gera o hash. Então, existe algum benefício em adicionar uma string aleatória extra (a mesma string) à senha antes do hashing? Isso é:

# app_wide_string = one-time generated, random 64 7-bit *character* string.
hash = sha256_hex( unique_user_id + app_wide_string + user_supplied_password );

Eu já vi isso sugerido, mas não entendo o que ganho com o sal por usuário. Se alguém quisesse forçar o ataque, eles saberiam que "app_wide_string" e usariam isso quando executassem seu ataque de dicionário, certo?

Existe uma boa razão para usar o bcrypt sobre o meu próprio rolo como descrito acima? Talvez o fato de eu estar fazendo essas perguntas seja motivo suficiente?

BTW - Acabei de cronometrar uma função hash existente que tenho e no meu laptop e posso gerar cerca de 7000 hashes por segundo. Não é exatamente um ou dois segundos que são frequentemente sugeridos.

Alguns links relacionados:

usando sha256 como hashing e salga com ID do usuário

SHA512 vs. Blowfish e Bcrypt

Qual é o comprimento ideal para o sal da senha do usuário?

Sua resposta

2   a resposta
8

31, cada incremento cria um tempo requerido exponencial, eu realmente fiz um gráfico, em um fator de trabalho de 14 já está levando mais de um segundo, assim como computadores ficam mais rápidos e mais rápidos você só precisa alterar um parâmetro e, claro, atualizar seus hashes de senha ...

Minha principal preocupação com o bcrypt é que, se o fator de trabalho estiver definido como alto, ele poderá sobrecarregar seu sistema, já que vários usuários estão tentando efetuar login, assim você pode ajustá-lo, dependendo do número de logons simultâneos e dos recursos do sistema. ..

Os sais ainda são necessários, seu objetivo principal é impedir ataques off-line, se o espaço salgado for grande, então o adversário não será capaz de gerar a tabela de consulta, o sal de 64 bits parece um pouco baixo, o bcrypt tem 128 bit sais juntamente com o fator trabalho torna um grande desafio para ataques offline ... e sim o sal deve ser aleatório para cada senha, bcrypt irá gerar um para você, se você usar o mesmo sal para cada senha, então você fez isso mais fácil para o adversário comprometer todas as senhas usando um ataque online.

Bcrypt realmente brilha por ataques online, se você definiu o fator trabalho corretamente, porque mesmo se eu pegar o hash, quis dizer se o 'adversário' pegar o hash, o fator trabalho torna realmente doloroso passar por um dicionário inteiro, tendo vários dias e se a senha não estiver no dicionário, então estou realmente com problemas porque um ataque de força bruta será épico, o espaço de bits da senha para o bcrypt é bastante grande, embora finito :)

O Sha256 pode demorar algum tempo agora, mas eventualmente os computadores ficarão cada vez mais rápidos e será bastante fácil para os ataques, os caras do unix acharam que a cripta era tão lenta que nunca seria um problema, e hoje eu fiz um ataque online em segundos, ataque offline em dias, um ataque de força bruta (passando por todo o espaço de bits da senha) em semanas ...

você quer que o sal seja tão grande e aleatório quanto possível, usando apenas números facilita a iteração sobre todos os ids possíveis.
Vários sha256 podem levar um segundo agora, mas no futuro não será mais eficaz, o poder de processamento dos computadores cresce exponencialmente e, portanto, você quer um algoritmo que possa ser configurado como tal.
você está fazendo a coisa certa fazendo perguntas e fazendo sua lição de casa se mais pessoas fizessem isso, não teríamos tantas brechas
em relação ao ponto 2: um hash repetidamente aplicado não pode ser escalonado exponencialmente? Eu argumento que pode, eles podem ser aplicados tanto quanto desejado. por exemplo, hoje eu aplico sha-512 10 ^ 3 vezes. amanhã eu aplico 10 ^ 4. Janus Troelsen
Obrigado. E como acompanhamento, a adição de uma string de "aplicativo inteiro" (como no meu exemplo acima) à senha antes do hashing fornece algum benefício? Parece que um sal aleatório é suficiente, correto? user1446426
dificulta ataques off-line (dicionário e força bruta), dependendo da entropia, já que essas strings não serão encontradas, mas não fazem nada por ataques online, onde o adversário tem o hash e o sal, já que eles precisam ser mantido em texto simples, para fins de verificação, portanto, se seu banco de dados ou seus hashes forem comprometidos, os sais não são muito úteis, lembre-se de sais dissuadidos ataques offline, fator de trabalho dissuadido ataques online, a outra questão é hash colisões buts thats a just baixa ocorrência ... bcrypt com um fator de trabalho appropraite deve ser bom. Samy Vilar
@JanusTroelsen Não tenho certeza do que você quer dizer compoint 2, o que você está descrevendo não pode ser aplicado ao ponto 2, já que assumindo um fator constante, desde que eu fosse bastante ambíguo, quanto ao aumento do 'fator', você teria que calculá-lo corretamente para corresponder às melhorias da CPU, mesmo usando bcrypt you ainda tem que fazer o mesmo, mas já está bem sintonizado para isso. Eventualmente, as CPUs irão melhorar ao ponto de podermos percorrer todo o espaço-bit, até lá teremos descoberto outra coisa (espero) ... Samy Vilar
Esta resposta é um começo útil, mas poderia ser melhorado 1) definindo ataques "online" versus "offline" (como aqui significava - normalmente esses termos significam se alguém está conectado à internet, mas eu acho que você quer dizer outra coisa ); 2) explicando porque a string "app-wide" ajuda (o que eu acho que só faz se o ataque fornecer acesso ao banco de dados, mas não ao código); 3) de que forma o parâmetro de sintonia do bcrypt é mais fácil (ou melhor) de usar que um único parâmetro usado como um expoente para controlar o número de aplicações SHA256, de acordo com o comentário de Janus Troelsen. Paul Lynch
0

ypt () usa apenas 16 bits?)

Você normalmente usaria um sal gerado aleatoriamente e, em seguida, armazenaria esse hash junto com a senha criptografada. Não importa que o invasor também tenha acesso ao sal - o objetivo é evitar que uma tabela de consulta seja usada, forçando o invasor a forçar cada hash individualmente.

crypt apenas armazena o sal e o hash em uma única string, junto com o algoritmo a ser usado.

Ele ainda precisaria de uma tabela separada por id. A menos que esse esquema fosse comum o suficiente para cada atacante ter algumas centenas de milhares de tabelas de pesquisa pré-geradas por aí, não haveria nenhum ganho. troelskn
Eu acho que o problema com um ID de usuário único para um salt é que, em seguida, o invasor pode ter uma tabela de pesquisa separada para cada salt, o que não seria viável se o salt fosse uma string longa e aleatória. Paul Lynch

Perguntas relacionadas