Suponha que você tenha a liberdade de decidir como as senhas em hash devem ser armazenadas em um DBMS. Existem fraquezas óbvias em um esquema como este?

Para criar o valor de hash armazenado no DBMS, leve:

Um valor que é exclusivo para a instância do servidor DBMS como parte do sal,E o nome de usuário como uma segunda parte do sal,E crie a concatenação do sal com a senha real,E hash toda a string usando o algoritmo SHA-256,E armazene o resultado no DBMS.

Isso significaria que qualquer pessoa que quisesse criar uma colisão deveria fazer o trabalho separadamente para cada nome de usuário e cada instância do servidor DBMS separadamente. Eu planejaria manter o mecanismo de hash real um pouco flexível para permitir o uso do novoNIST algoritmo de hash padrão (SHA-3) que ainda está sendo trabalhado.

O 'valor que é exclusivo para a instância do servidor DBMS' não precisa ser secreto - embora não seja divulgado casualmente. A intenção é garantir que, se alguém usar a mesma senha em diferentes instâncias do servidor DBMS, os hashes registrados sejam diferentes. Da mesma forma, o nome do usuário não seria secreto - apenas a senha apropriada.

Haveria alguma vantagem em ter a senha primeiro e o nome do usuário e o 'valor único' em segundo, ou qualquer outra permutação das três fontes de dados? Ou que tal intercalar as cordas?

Eu preciso adicionar (e gravar) um valor de sal aleatório (por senha), bem como as informações acima? (Vantagem: o usuário pode reutilizar uma senha e ainda assim, provavelmente, obter um hash diferente registrado no banco de dados. Desvantagem: o sal tem que ser registrado. Eu suspeito que a vantagem supera consideravelmente a desvantagem.)

Existem muitas questões SO relacionadas - é improvável que essa lista seja abrangente:

Criptografando / Hashing de senhas de texto simples no banco de dadosSecure hash and salt para senhas do PHPA necessidade de esconder o sal para um hashMd5 do lado do cliente hash com sal do tempoCriptografia de senha simplesGeração de sal e software de código abertoHashes de senha: campos binários de comprimento fixo ou campo de string único?

Eu acho que as respostas para essas perguntas suportam meu algoritmo (embora se você simplesmente usar um salt aleatório, então os componentes 'unique value per server' e username são menos importantes).