Porquê? SHA-256 sozinho é inadequado para armazenamento de senha
Os valores de verificação de arquivos e o armazenamento de senhas do lado do servidor resolvem problemas diferentes. O armazenamento de senhas também deve fazer com que cada uma das senhas off-line adivinhe caro.
Neste guia
Hashing não é criptografia: não existe uma operação de descriptografia correspondente. No entanto, após um vazamento de banco de dados, um atacante pode adivinhar e compará-los com registros roubados sem passar os limites da taxa de login do seu aplicativo.
A velocidade da SHA torna-se uma desvantagem
SHA-256 é útil para verificações de integridade e muitas aplicações criptográficas. A sua velocidade é indesejável para o armazenamento de senhas. SHA256(salt + password) Não faz suposições suficientemente caras. Sal e custo computacional servem diferentes propósitos.
Não invente um formato de credencial ou um loop de hashes comuns. Use uma biblioteca mantida com senha.
Escolha uma função dedicada de senhas
OWASP prefere Argon2id Para novos sistemas, com o scriptografar como uma alternativa quando não estiver disponível. PBKDF2 O Bcrypt continua a ser relevante para sistemas legados, mas tem limitações, incluindo o comprimento de entrada.
Use as funções de biblioteca para criação e verificação, geração de sal e armazenamento de parâmetros. Escolha os parâmetros de custo da orientação atual e medições no servidor alvo. Conta para logins simultâneos e limites de recursos: hashing caro não deve tornar a negação do serviço trivial. A limitação de taxa on-line permanece necessária.
Compreender sal e pimenta
Um sal é aleatório e único para cada registro; ele não precisa ser secreto. Guarde o identificador do algoritmo e os parâmetros de verificação também, muitas vezes dentro do registro codificado da biblioteca.
Um pimentão é um segredo opcional mantido fora da base de dados de senhas. Ele pode ajudar em alguns cenários de quebra, mas complica a rotação e o gerenciamento de chaves. Ele não substitui nem sal nem uma função de hashing adequada.
Atualizar registros após verificação bem-sucedida
Em um login bem- sucedido, verifique primeiro o registro antigo e então repita a senha enviada se os parâmetros estiverem desatualizados. Você não pode recuperar senhas originais do hashes existente para migrar todo o banco de dados. As contas inativas precisam de uma política de redefinição ou migração separada. Rehashing não desfaz um vazamento anterior.
Antes da implantação, teste senhas incorretas, migração legada, limites de comprimento e carga. Nunca registre senhas de teste ou envie-as para análise.