A necessidade de esconder o sal para um hash

https://stackoverflow.com/questions/213380

03-07-2019
|

Pergunta

No trabalho, temos duas teorias concorrentes para sais. Os produtos Eu trabalho em usar algo como um nome de usuário ou número de telefone para o sal do hash. Essencialmente algo que é diferente para cada usuário, mas está prontamente disponível para nós. O outro produto gera aleatoriamente um sal para cada utilizador e muda a cada vez que o utilizador muda a palavra-passe. O sal é então criptografada no banco de dados.

A minha pergunta é se a segunda abordagem é realmente necessário? Posso entender de uma perspectiva puramente teórica de que é mais seguro do que a primeira abordagem, mas o que dizer de um ponto de vista prático. Agora para autenticar um usuário, o sal deve ser sem criptografia e aplicado as informações de login.

Depois de pensar sobre isso, eu simplesmente não consigo ver um ganho real de segurança a partir desta abordagem. Alterar o sal de conta para conta, ainda torna extremamente difícil para alguém tentar força bruta o algoritmo de hash mesmo que o atacante estava ciente de como determinar rapidamente o que era para cada conta. Isso vai na suposição de que as senhas são suficientemente fortes. (Obviamente encontrar o hash correto para um conjunto de senhas onde estão todos os dois dígitos é significativamente mais fácil do que encontrar o hash correto de senhas que são 8 dígitos). Estou incorreto na minha lógica, ou há algo que eu estou ausente?

EDIT: Ok então aqui está a razão pela qual eu acho que é muito discutível para criptografar o sal. (Deixe-me saber se estou no caminho certo).

Para a seguinte explicação, vamos supor que as senhas são sempre 8 caracteres e o sal é de 5 e todas as senhas são compostas por letras minúsculas (ele só faz a matemática mais fácil).

Ter um sal diferente para cada um dos meios de entrada que não é possível utilizar a mesma tabela do arco-íris (na verdade, tecnicamente eu poderia se eu tivesse um tamanho suficiente, mas vamos ignorar que para o momento). Esta é a verdadeira chave para o sal do que eu entendo, porque a rachar todas as contas que tenho que reinventar a roda, por assim dizer para cada um. Agora, se eu sei como aplicar o sal correta de uma senha para gerar o hash, eu faria isso porque um sal realmente apenas estende o comprimento / complexidade da frase hash. Então eu estaria cortando o número de combinações possíveis que eu precisaria para gerar a "conhecer" Eu tenho a senha + sal de 13 ^ 26-8 ^ 26, porque eu sei o que o sal é. Agora que torna mais fácil, mas ainda muito difícil.

Assim, para criptografar o sal. Se eu sei que o sal é criptografada, eu não iria tentar e descriptografar (supondo que eu sei que tem um nível suficiente de criptografia) pela primeira vez. Eu ignorá-lo. Em vez de tentar descobrir como decifrá-lo, de volta ao exemplo anterior vai gostaria apenas de gerar uma tabela de arco-íris maior que contém todas as chaves para o 13 ^ 26. Não sabendo o sal iria me atrasar, mas eu não acho que seria adicionar a tarefa monumental de tentar quebrar a criptografia de sal em primeiro lugar. É por isso que eu não acho que vale a pena. Pensamentos?

Aqui está um link que descreve como senhas longas irá realizar-se sob um ataque de força bruta: http://www.lockdown.co.uk/?pg=combi

Solução

A resposta aqui é perguntar-se o que você está realmente tentando proteger de? Se alguém tem acesso ao seu banco de dados, então eles têm acesso aos sais criptografados, e eles provavelmente têm acesso ao seu código também. Com tudo o que eles poderiam decifrar os sais criptografados? Se sim, então a criptografia é muito bonito de qualquer maneira inútil. O sal é realmente lá para torná-lo por isso não é possível formar uma tabela de arco-íris para quebrar seu banco de dados de senha toda de uma vez se ele for arrombada. A partir desse ponto de vista, desde que cada sal é único, não há diferença, um ataque de força bruta seria necessário com os seus sais ou os sais criptografados para cada senha individual.

Outras dicas

Escondendo um sal é desnecessário.

Um sal diferente deve ser usado para cada hash. Na prática, isso é fácil de conseguir, obtendo 8 ou mais bytes de gerador de números aleatórios qualidade criptográfica.

A partir de um resposta anterior da mina :

O sal ajuda para frustrar ataques de dicionário pré-calculado.

Suponha que um atacante tem uma lista de senhas prováveis. Ele pode botar para cada e compará-lo com o hash da senha de sua vítima, e ver se ele partidas. Se a lista é grande, isso pode levar um longo tempo. Ele não faz quer passar muito tempo em seu próximo alvo, então ele registra o resultado em um "dicionário" onde um hash pontos da sua entrada correspondente. E se a lista de senhas é muito, muito longo, ele pode usar técnicas como a Arco-íris Tabela de poupar algum espaço.

No entanto, suponha que seu próximo alvo salgada sua senha. Mesmo que o atacante sabe que o sal é, sua mesa precomputed é inútil-o sal muda o hash resultante de cada palavra-passe. Ele tem que re-hash de todas as senhas em sua lista, a aposição do alvo sal para a entrada. Cada sal diferente requer um diferente dicionário, e se forem utilizados sais suficientes, o atacante não terá quarto para armazenar dicionários para todos eles. Negociação espaço para poupar tempo não é mais uma opção; o atacante deve cair de volta para hash cada senha em sua lista para cada alvo que ele quer atacar.

Assim, não é necessário para manter o segredo sal. Garantindo que o atacante não tem um dicionário pré-calculado correspondente a essa nomeadamente o sal é suficiente.

Depois de pensar sobre isso um pouco mais, eu percebi que enganar-se em pensar que o sal pode ser escondido é perigoso. É muito melhor para assumir o sal não pode ser escondido, e projetar o sistema para ser seguro, apesar disso. Eu fornecer uma explicação mais detalhada em outra resposta.

O meu entendimento de "sal" é que faz rachar mais difícil, mas ele não tenta esconder os dados extras. Se você está tentando obter mais segurança, fazendo o sal "segredo", então você realmente só quero mais bits em suas chaves de criptografia.

A segunda abordagem é apenas um pouco mais seguro. Sais de proteger os usuários de ataques de dicionário e ataques tabela arco-íris. Eles tornar mais difícil para um atacante ambicioso para comprometer todo o sistema, mas ainda são vulneráveis ??a ataques que estão focados em um usuário de seu sistema. Se você usar a informação que está disponível publicamente, como um número de telefone, e que o atacante se torna cientes deste , então você salvou um passo em seu ataque. É claro que a questão é discutível se o atacante recebe o seu banco de dados inteiro, sais e tudo.

EDIT: Depois de re-leitura sobre esta resposta e alguns dos comentários, ocorre-me que algumas das confusões pode ser devido ao fato de que eu estou apenas comparando os dois muito específico casos apresentados na pergunta: sal aleatório vs sal não-aleatória. A questão da usando um número de telefone como um sal é discutível se o atacante recebe o seu banco de dados inteiro, não a questão do uso de um sal em tudo.

Um sal escondido não é mais sal. É pimenta. Tem a sua utilização. É diferente de sal.

A pimenta é uma chave secreta adicionado ao sal + senha que torna o hash em um (Message Authentication Code Hash Based) HMAC. Um hacker com acesso para a saída de hash e o sal pode, teoricamente, a força bruta adivinhar uma entrada que vai gerar o hash (e, por conseguinte, passar validação na caixa de texto de senha). Ao adicionar pimenta-lo a aumentar o espaço do problema de uma forma criptograficamente aleatória, tornando o intratável problema sem hardware sério.

Para mais informações sobre pimenta, verifique aqui .

Veja também hmac .

Aqui está um exemplo simples que mostra por que é ruim ter o mesmo sal para cada hash

Considere a tabela a seguir

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)

Caso 1 quando o sal 1 é o mesmo que salt2 Se hash2 é substituído por hash1 então o usuário 2 poderia logon com utilizador 1 senha

Caso 2 quando o sal 1 não é o mesmo salt2 Se hash2 é substituído por hash1 então user2 não pode logon com usuários 1 senha.

... algo como um nome de usuário ou número de telefone para o sal do hash. ...

A minha pergunta é se a segunda abordagem é realmente necessário? Posso entender de uma perspectiva puramente teórica de que é mais seguro do que a primeira abordagem, mas o que dizer de um ponto de vista prático?

Do ponto de vista prático, um sal é um detalhe de implementação. Se você nunca mudar a forma como informações do usuário é coletada ou mantido - e ambos os nomes de usuário e números de telefone, por vezes, mudar, para usar seus exemplos exatas - então você pode ter comprometido a sua segurança. Você quer uma tal mudança virados para o exterior para ter preocupações de segurança muito mais profundas?

Does parar a exigência de que cada conta tem uma necessidade número de telefone para envolver uma revisão de segurança completa para se certificar de que você não abriu essas contas a um comprometimento da segurança?

Existem duas técnicas, com objetivos diferentes:

O "sal" é usado para fazer duas senhas de outra forma iguais criptografar de forma diferente. Desta forma, um intruso não pode eficientemente usar um ataque de dicionário contra toda uma lista de senhas criptografadas.
A (compartilhado) "segredo" é adicionado antes de hashing uma mensagem, de modo que um intruso não pode criar suas próprias mensagens e tê-los aceito.

I tendem a esconder o sal. Eu uso 10 bits de sal, antecedendo um número aleatório de 1 a 1024 para o início da senha antes de hash-lo. Ao comparar a senha que o usuário entrou com o hash, eu ciclo 1-1024 e tentar cada valor possível de sal até que eu encontre a partida. Isso leva menos do que 1/10 de um segundo. Eu tive a idéia de fazê-lo desta forma desde o PHP password_hash password_verify . No meu exemplo, o "custo" é de 10 para 10 bits de sal. Ou do que outro usuário disse, escondido "sal" é chamado de "pimenta". O sal não é criptografada no banco de dados. É de ataque de força bruta para fora. Não faria tabela de arco-íris necessário inverter o hash 1000 vezes maior. Eu uso sha256 porque é rápido, mas ainda é considerado seguro.

Realmente, isso depende de que tipo de ataque que você está tentando proteger seus dados.

O objetivo de um sal exclusivo para cada senha é para evitar um ataque de dicionário contra todo o banco de dados de senha.

Criptografar o sal exclusivo para cada senha tornaria mais difícil de decifrar uma senha individual, sim, mas você deve pesar se há realmente muito de um benefício. Se o atacante, pela força bruta, considera que esta string:

Marianne2ae85fb5d

hashes para um hash armazenado no DB, que é realmente difícil de descobrir o que parte é a passagem e qual parte é o sal?

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow