Supongamos que tiene la libertad de decidir cómo se almacenarán las contraseñas con hash en un DBMS. ¿Hay debilidades obvias en un esquema como este?

Para crear el valor de hash almacenado en el DBMS, tome:

Un valor que es único para la instancia del servidor DBMS como parte de la sal,Y el nombre de usuario como segunda parte de la sal,Y cree la concatenación de la sal con la contraseña real,Y hash toda la cadena usando el algoritmo SHA-256,Y almacenar el resultado en el DBMS.

Esto significaría que cualquier persona que quiera crear una colisión debería tener que hacer el trabajo por separado para cada nombre de usuario y cada instancia de servidor DBMS por separado. Planeo mantener el mecanismo de hash real un tanto flexible para permitir el uso del nuevoNIST algoritmo hash estándar (SHA-3) que todavía se está trabajando.

El 'valor que es único para la instancia del servidor DBMS' no necesita ser secreto, aunque no se divulgará de manera casual. La intención es asegurar que si alguien usa la misma contraseña en diferentes instancias del servidor DBMS, los hashes registrados serían diferentes. Del mismo modo, el nombre de usuario no sería secreto, solo la contraseña correcta.

¿Habría alguna ventaja en tener la contraseña primero y el nombre de usuario y el 'valor único' en segundo lugar, o cualquier otra permutación de las tres fuentes de datos? ¿O qué hay de intercalar las cuerdas?

¿Debo agregar (y registrar) un valor de sal aleatorio (por contraseña) así como la información anterior? (Ventaja: el usuario puede reutilizar una contraseña y aún así, probablemente, obtener un hash diferente registrado en la base de datos. Desventaja: la sal debe ser registrada. Sospecho que la ventaja supera considerablemente la desventaja.)

Hay bastantes preguntas de SO relacionadas; es poco probable que esta lista sea exhaustiva:

Encriptación / Hashing contraseñas de texto plano en la base de datosHash y sal seguros para las contraseñas de PHPLa necesidad de esconder la sal para un hachís.Hash MD5 del lado del cliente con sal de tiempoCifrado de contraseña simpleGeneración de sal y software de código abierto.Hash de contraseña: ¿campos binarios de longitud fija o campo de cadena única?

Creo que las respuestas a estas preguntas son compatibles con mi algoritmo (aunque si simplemente usa un salt aleatorio, el 'valor único por servidor' y los componentes de nombre de usuario son menos importantes).