Sou um iniciante em criptografia e procuro entender em termos muito simples o que é uma criptografia " salt " é, quando posso precisar usá-lo e por que devo ou não usá-lo.
Posso obter um muito simples e uma explicação clara (nível de iniciante)?
Se você souber de alguma referência sobre o tópico, ela também será útil.
Resposta
A razão pela qual os sais são usados é que as pessoas tendem a escolher as mesmas senhas, e não ao acaso. Muitas senhas usadas por aí são palavras reais curtas, para torná-las fáceis de lembrar, mas isso também permite um ataque.
Como você deve saber, as senhas geralmente não são armazenadas em texto não criptografado, mas em hash. Se você não tiver certeza da finalidade de uma função hash, leia primeiro.
Agora, o que os invasores podem fazer é simplesmente gerar uma lista de senhas comuns e seus hashes correspondentes. Se as senhas comuns estiverem sendo usadas, os hashes que um site armazenou com a tabela revelarão as senhas ao invasor.
A salt é simplesmente adicionado para tornar uma saída de hash de senha exclusiva até mesmo para usuários adotando senhas comuns . Seu objetivo é tornar inúteis os ataques baseados em pré-computação. Se sua senha for armazenada com um sal exclusivo, qualquer tabela de hash de senha pré-computada visando hashes de senha sem sal ou direcionar uma conta com um sal diferente não ajudará a quebrar a senha de sua conta. Um sal longo gerado aleatoriamente (usando /dev/urandom) deve ser globalmente exclusivo . Assim, os sais podem ser usados para fazer pre Ataques de computação totalmente ineficazes.
A maneira mais simples de combinar o salt e a senha é simplesmente concatená-los, ou seja, o valor de hash armazenado é Hash(salt||password). senha password1 agora torna-se magicamente, por exemplo, 6$dK,3gCA%Jpassword1 que é improvável de ser encontrada na tabela de um cracker de senha.
O salt pode ser armazenado completamente no clear no banco de dados, próximo ao valor hash. Assim que o invasor tiver o banco de dados e quiser encontrar as senhas, ele precisa gerar a tabela pré-calculada para cada sal individualmente, uma operação cara.
Outra maneira de ajudar na defesa contra o cracking de senha offline é executar alongamento de senha, ou seja. tornando um hash de senha mais lento para computar para qualquer pessoa, incluindo o serviço de login e crackers de senha. Um método usado para esticar as senhas é alcançado iterando a função hash muitas vezes, ou seja, armazenando Hash(Hash(Hash(Hash…(Hash(salt||password)))…).
Outra ideia comum relacionada à salga é chamada de pimenta . Ou seja, outro valor aleatório concatenado à senha, de forma que o valor armazenado seja Hash(pepper||salt||password). A pimenta então não é armazenada . O servidor de login e o cracker de senha precisam aplicar força bruta ao valor de pimenta desconhecido, reduzindo as comparações de hash de senha para ambas as partes.
De 2013 a 2015, um hashing de senha competição foi realizada para buscar um algoritmo de alongamento de senha melhor. O vencedor foi o algoritmo Argon2 . Recomenda-se aos programadores usar Argon2 em vez de implementar seu próprio algoritmo .
Comentários
- Então, essencialmente, quando você tem apenas uma ou 2 senhas armazenadas no banco de dados, o uso de salt é efetivamente inútil? O que eu entendo é que isso só é útil quando o número de senhas armazenadas no banco de dados não é pequeno.
- @AbhinavChoudhury: Não, ele protege contra rainbow tables – ou seja, tabelas pré-calculadas para um hash específico. Um exemplo: pegue uma senha " password1 ". Se você não ' sal, você ' armazena HASH (" senha1 ") em seu banco de dados. Agora, se um invasor obtiver seus registros e tiver HASH (*) pré-calculado para todas as senhas de 9 caracteres, ele pode recuperar a senha. Se, em vez disso, você salted a senha, HASH (' somesaltforyou ' || ' senha1 ') NÃO estará na tabela arco-íris dos atacantes (uma vez que ' tem mais de 9 caracteres).
- " O salt pode ser armazenado completamente no clear no banco de dados, próximo ao valor hash " – – essa parte nunca fez sentido para mim; Eu gostaria de saber se você poderia expandir isso
- O objetivo do sal é garantir que o hash não seja encontrado em uma tabela pré-computada. Deve ser armazenado para verificar a senha (caso contrário, ' sa " pimenta "). O sal não deve ser " secreto ", apenas para tornar a senha exclusiva. Isso, é claro, significa que cada senha armazenada deve ter seu próprio sal exclusivo (e aleatório).
Resposta
Você pode me ajudar a entender o que é um “sal” criptográfico?
No contexto da senha criação, um “sal” são dados (aleatórios ou não) adicionados a uma função hash para tornar a saída em hash de uma senha mais difícil de quebrar.
Quando posso precisar usá-lo?
Sempre.
Por que devo ou não devo usá-lo?
Você deve sempre usar um valor salt com suas funções hash, pelos motivos explicados abaixo.
É geralmente verdade que as pessoas escolhem senhas fracas, e é certamente verdade que existem gigabytes de tabelas de arco-íris disponíveis publicamente repletas de valores hash que as representam. Portanto, quando alguém cria uma conta em seu serviço e seleciona uma senha para proteger sua identidade, você pode apostar que a senha escolhida será 1) comum, 2) insegura e 3) disponível para referência cruzada em tabelas de pesquisa.
Por exemplo, a senha Nowayin1 quando o hash via MD5 é 6f367d65bc74b88e21fb9959487ffa3a e obviamente não é uma boa escolha. Mesmo que pareça normal (e não parece), o fato de o hash MD5 da senha aparecer em bancos de dados abertos torna-o inútil.
Mas isso é apenas MD5 de 128 bits. Que tal algo mais forte, como SHA1 (160 bits) ou mesmo Whirlpool (512 bits)?
Mesmo problema.
Por exemplo, P @ $$ word com SHA1 é 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 e “703de9e2ce”>
1qazXSW @ hash com Whirlpool é 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf .
O problema raiz com todas essas senhas, e bilhões mais como elas, é o fato de que seus hashes comumente usados se tornaram de conhecimento comum.
Uma senha salt muda isso.
Se um valor aleatório (o salt) for adicionado à senha selecionada do usuário, então o hash SHA1 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 não revelaria mais P como a senha do usuário, porque o valor hash na tabela rainbow não corresponderia mais a ele.
E não demoraria muito. Um pequeno valor aleatório de 16 bits, por exemplo, renderia 65.536 variantes de cada valor com hash nas tabelas de pesquisa. Portanto, um banco de dados de 15 bilhões de entradas precisaria agora de mais de 983 bilhões de hashes para contabilizar o sal.
Então, esse é o ponto de salgar seus hashes, para impedir a pesquisa e as tabelas de arco-íris. Mas não “pendure seu chapéu em um hash salgado, porque os hackers não perderão muito tempo usando tabelas de arco-íris para descobrir suas senhas.
Eles usarão um sistema de cluster de 25 GPU de cinco servidores executando Hashcat que pode queimar 350 bilhões de suposições por segundo crackeando hashes para cada senha de oito caracteres concebível contendo letras maiúsculas e minúsculas, números e caracteres especiais, em pouco menos seis horas. (E isso foi em 2012.)
Técnicas como alongamento de teclas que fazem os hashes rodarem mais devagar podem ser usadas para compensar a velocidade desse hardware, tornando ataques de dicionário e de força bruta lentos demais para valer a pena , mas o hardware fica cada vez mais rápido.
ATUALIZAÇÃO 2018:
As práticas recomendadas atuais incluem hash com segurança de suas senhas com Argon2i (preferível a scrypt), uma função de memória difícil que é muito resiliente para FPGAs, GPUs de múltiplos núcleos e módulos ASIC dedicados usados para quebrar facilmente frases-senha não esticadas. Na implementação do PHP7 do Argon2, o salt é tratado internamente para você.
Resposta
Vou tentar responder a uma parte da sua pergunta que até agora foi negligenciada:
quando posso precisar usá-lo e por que devo / não devo usá-lo.
A resposta curta é que, como amador, você não deve usar criptografia em um nível que exija o tratamento direto de sais.
Por exemplo, o bcrypt o algoritmo de hash de senha usa sais internamente. Mas não expõe esse fato aos desenvolvedores que o usam – você simplesmente passa a senha para bcrypt (e opcionalmente, um parâmetro que define o “nível de esforço da CPU “necessário para gerar o hash) e retorna o hash. Quando você precisar validar se uma senha está correta, você passa bcrypt a senha e o hash gerado anteriormente. Ele indicará se a senha foi ou não usada para gerar o hash.
Não siga o conselho dado aqui e tente fazer o hash de suas próprias senhas usando um salt. É um detalhe de implementação de baixo nível, e se você estiver trabalhando em um nível onde esse tipo de coisa é necessária, você está trabalhando em um nível de abstração muito baixo. A criptografia é muito difícil de ser feita corretamente, e a Internet está repleta de desenvolvedores bem-intencionados “esquemas de hash de senha criados internamente e completamente inseguros.
Resposta
Citando “ Exam Ref 70-486 Developing ASP.NET MVC 4 Web Applications (MCSD): Developing ASP.NET MVC 4 Web Applications ” por William Penberthy, Pearson Education, 15 de setembro de 2013:
Salting é um processo que fortalece a criptografia de arquivos e hashes, tornando-os mais difíceis de quebrar. Salting adiciona uma string aleatória no início ou no final do texto de entrada antes de fazer hash ou criptografar o valor. Ao tentar quebrar uma lista de senhas, por exemplo, os hackers precisam contabilizar o salt, bem como as informações de senha possíveis antes de poderem quebrar no aplicativo. Se cada valor sendo salgado for atribuído a um valor sal diferente, a capacidade de criar uma tabela de valores de senha potenciais para um pa O programa de quebra de palavras se torna difícil de manejar.
Resposta
Um sal é um número aleatório que é necessário para acessar os dados criptografados, junto com a senha.
Se um invasor não souber a senha e estiver tentando adivinhá-la com um ataque de força bruta, então todas as senhas ele tentará deve ser tentado com cada valor de sal.
Então, para um sal de um bit (0 ou 1), isso torna a criptografia duas vezes mais difícil de quebrar dessa maneira. Um sal de dois bits o torna quatro vezes mais duro, um sal de três bits oito vezes mais duro etc. Você pode imaginar como é difícil quebrar senhas com criptografia que usa um sal de 32 bits!
Comentários
- Não. O sal geralmente é considerado conhecido pelo invasor. Nesse caso, além de algum limite baixo, o salt não melhora a segurança.
- " O salt geralmente é considerado conhecido pelo invasor " – > Quem está assumindo isso?
- @Mike: Quem? Alguém diz " Você deve sempre presumir que o invasor conhece o sal. ". Pessoas em outra página diz " Sais são públicos ", e mais tarde diz " que os sais são conhecidos, porque ' é o uso padrão da indústria da palavra sal. " Outro diz " o sal é de conhecimento público, ou pelo menos deve ser tratado como público conhecimento. ".