Qual é o comprimento ideal para a senha do usuário salt? [fechadas]

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?

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.

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.

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.

Wikipedia :

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.

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.