Qualquer sal obviamente ajudará ao salgar e hash a senha de um usuário. Existem práticas recomendadas por quanto tempo o sal deve durar? Estarei armazenando o sal na minha tabela de usuários, portanto, gostaria da melhor troca entre tamanho e segurança de armazenamento. Um sal aleatório de 10 caracteres é suficiente? Ou preciso de algo mais?
Não tenho uma recomendação sobre o comprimento do sal, mas as respostas que estão aparecendo aqui têm muitas informações ruins. Seu sal deve definitivamente: - ser aleatório - ser por segredo (nenhum valor armazenado na imagem do programa ou no arquivo de configuração). O sal não é um segredo criptográfico, portanto, armazená-lo na sua mesa não é problema. O único objetivo de um salt é garantir que, quando diferentes instâncias do mesmo item sejam hash (ou criptografadas), você obtenha um resultado diferente.
Para quem não sabe o que é sal: <a href=" en.wikipedia.org/wiki/Salt_(cryptography)"> Sal (criptografia) </a> na Wikipedia
— David Koelle
Ou se houver uma proporção ideal entre o comprimento do sal e o comprimento da saída de hash? O sal de 8 bytes pode ser suficiente para o HMAC-SHA-256, mas não o HMAC-SHA-512.
— Crend King
O sal criptograficamente aleatório do mesmo tamanho da saída da função hash significa que um ataque "tente todos os sais possíveis" (mais um dicionário de senhas) exige tanto esforço quanto um ataque "tente todos os resultados possíveis de hash" - que é uma força bruta padrão . Um sal mais curto significa que você pode ter um dicionário de sal mais um dicionário de senha como ataque de força bruta.
-1 É certo que nem sequer tenta responder à pergunta.
— user359996
A maioria dessas respostas é um pouco equivocada e demonstra uma confusão entre sais e chaves criptográficas. O objetivo de incluir sais é modificar a função usada para hash da senha de cada usuário, para que cada hash da senha armazenada precise ser atacado individualmente. O único requisito de segurança é que eles sejam únicos por usuário, não há benefício em serem imprevisíveis ou difíceis de adivinhar.
Os sais precisam apenas ser longos o suficiente para que o sal de cada usuário seja único. É improvável que os sais aleatórios de 64 bits se repitam, mesmo com um bilhão de usuários registrados, então isso deve ser bom. Um sal repetidamente isolado é uma preocupação de segurança relativamente pequena, pois permite que um invasor pesquise duas contas ao mesmo tempo, mas no conjunto não irá acelerar muito a pesquisa em todo o banco de dados. Mesmo os sais de 32 bits são aceitáveis ​​para a maioria dos propósitos, na pior das hipóteses, aceleram a pesquisa de um invasor em cerca de 58%. O custo do aumento de sais além de 64 bits não é alto, mas não há motivos de segurança para isso.
Há algum benefício em também usar um sal em todo o site sobre o sal por usuário, isso evitará possíveis colisões com hashes de senha armazenados em outros sites e o uso de tabelas arco-íris de uso geral, embora até 32 bits de sal é suficiente para tornar as mesas do arco-íris um ataque impraticável.
Ainda mais simples - e os desenvolvedores sempre ignoram isso - se você tiver IDs de usuário ou nomes de login exclusivos, eles funcionam perfeitamente bem. Se você fizer isso, adicione um sal em todo o site para garantir que não se sobreponha aos usuários de outro sistema que tiveram a mesma idéia brilhante.
— SecurityJoe
Há um benefício em que os sais sejam imprevisíveis. Um sal previsível pode ser previsto e usado em um ataque de tabela de hash. Por exemplo, se o seu salt for apenas o ID do usuário, uma tabela simples de hash alfa que seja longa o suficiente incluirá não apenas todas as senhas, mas todas as combinações de nome de usuário e senha.
Observe em relação ao seu último parágrafo, se você usar um sal em todo o site, deve ser exatamente isso: todo o site. Não abrange todo o aplicativo, ou seja, cada nova instância que você instala do seu aplicativo deve gerar um novo sal para todo o site. Por exemplo, se o Windows usasse o mesmo sal em todos os bancos de dados de autenticação do Windows, valeria a pena criar uma tabela arco-íris para esse sal, mas se toda instalação do Windows gerasse um novo sal, isso não aconteceria.
A questão não é realmente que o sal precisa ser difícil de adivinhar. O atacante não precisa adivinhar o sal: quem tem acesso ao hash já tem o sal. O problema é que, se seus sais são muito comuns (como nomes de usuário), eles podem ser os mesmos de outros sites e, nesse ponto, o invasor precisa de um conjunto muito menor de tabelas arco-íris para viabilizar ataques. É por isso que é mencionada a ideia de sal por local, para evitar esse tipo de colisão com outros locais.
Nota rápida: Se você estiver usando nomes de usuários como o salt, isso pode ser um problema se os nomes de usuários mudarem. Praticamente (apesar do que é dito nos documentos de design do cliente), descobri que os usuários geralmente desejam alterar nomes de usuários.
— SilentSteel 21/07
@ NateC-K, a ideia de sal por site de que você está falando se chama pimenta.
Os padrões atualmente aceitos para senhas de hash criam um novo salt de 16 caracteres para cada senha e armazena o salt com o hash da senha.
Obviamente, deve-se tomar cuidado criptográfico adequado para criar sal realmente aleatório.
O personagem está um pouco mal definido. Você deveria dizer byte .
@CodesInChaos Eu acredito que você média octeto ;-)
Oi! Parece que o artigo da wikipedia foi alterado - talvez você deva consultar en.wikipedia.org/wiki/PBKDF2 ou algo assim?
Ou melhor ainda: owasp.org/index.php/Password_Storage_Cheat_Sheet
Editar: Minha resposta abaixo responde à pergunta conforme solicitado, mas a resposta "real" é: basta usar bcrypt , scrypt ou Argon2 . Se você está fazendo perguntas como essa, certamente está usando ferramentas em um nível muito baixo.
Honestamente, não há razão defensável para que o sal não tenha o mesmo tamanho exato da senha com hash. Se você estiver usando o SHA-256, terá um hash de 256 bits. Não há razão para não usar um sal de 256 bits.
Mais de 256 bits não renderão matematicamente nenhuma melhoria na segurança. Porém, optar por um sal mais curto pode sempre acabar com uma situação em que uma mesa arco-íris atinge seu comprimento - especialmente com sais mais curtos.
Isso não é que muito grande; o usuário mal notará a diferença entre um hash de milissegundo e meio segundo, mais o hash de senha na verdade deve levar mais tempo para diminuir os ataques de força bruta - embora três ataques típicos bloqueados por 15 minutos sejam melhores. Você está "desperdiçando" ciclos de CPU para fazer isso? Sim, tanto faz. A CPU gasta mais tempo ociosa do que na maioria dos sites, então o que importa? Se você estiver enfrentando problemas de desempenho, expanda.
Os sais se defendem contra as mesas do arco-íris. Um sal de 512 bits com um hash de 256 bits ainda resultará em 256 bits de entropia na senha final.
— Stephen Touset 15/03
O hash lento é um recurso, não um bug.
— outis 15/09/11
Se você tiver um hash de 3 bits, o seu sal de 9999 bits ainda reduzirá até 3 bits possíveis de entropia. Uma tabela arco-íris teria apenas que encontrar três sais para cada senha que resultassem em uma saída diferente, que é um fator multiplicativo constante e, portanto, descartado do big-O.
— Stephen Touset 06/07/12
.................................................. .................................... sistema particular. O objetivo dos sais é interromper os ataques de pré-computação, para que os hashes não possam ser pesquisados ​​e imediatamente revertidos em texto simples . Com um salt de 9999 bits, sua senha permanece em segredo , enquanto que com um salt de 3 bits, sua senha agora é conhecida em todo o mundo (e eles podem usá-la para acessar suas outras contas, pois muitas pessoas reutilizam senhas). Acho divertido que 5 pessoas aqui tenham votado positivamente no seu comentário devido à palavra "entropia" nele.
Os métodos SHA2-crypt e bcrypt - usados ​​no Linux, BSD Unixes e Solaris - possuem sais de 128 bits. Esses valores maiores de sal tornam inviáveis ​​os ataques de pré-computação para praticamente qualquer tamanho de senha contra esses sistemas no futuro próximo.
O sal de 128 bits (16 bytes) será suficiente. Você pode representá-lo como uma sequência de 128 / 4 = 32dígitos hexadecimais.
— Andrii Nemchenko
Parece-me que um exemplo do que outros sistemas seguros usam é um ótimo exemplo do que é a melhor prática.
— Cjbarth #
@ mklement0 Obrigado, atualizei a resposta.
Uma resposta pode ser usar como tamanho de sal o valor que o hash que você usará fornece em termos de segurança.
Por exemplo, se você for usar o SHA-512, use sal de 256 bits, pois a segurança fornecida pelo SHA-512 é de 256 bits.