Digamos que tengo una base de datos y varias aplicaciones web separadas que comparten la base de datos. Si los hashes deben ser únicos y generados en el lado del servidor, ¿cómo puedo asegurarme de que estoy generando un hash único en varias aplicaciones?
Editar: por alguna razón, parece que he leído completamente la pregunta. La respuesta a continuación se aplica a otra pregunta que tiene poca similitud con la pregunta real.
En cuanto a su pregunta, una forma sencilla de garantizar la singularidad (con alta probabilidad) es usar la aleatoriedad: a partir de un PRNG criptográficamente fuerte, solo produzca 16 bytes aleatorios. Eso es 128 bits. Las matemáticas muestran que la primera reutilización se produce una vez que haya generado unos 20 billones de billones de valores de sal, es decir, no sucederá pronto .
Las aplicaciones también pueden usar un método de generación que trata de lograr la singularidad mediante el uso de la dirección MAC de la máquina, la hora actual, la identificación del proceso y todo lo demás. GUID están diseñados para hacer precisamente eso. Cada servidor simplemente puede solicitar un "nuevo GUID" cuando necesita un salt; un GUID se codifica como 16 bytes. De hecho, un método de generación de GUID es usar un PRNG criptográficamente fuerte, por lo que ambos métodos son en realidad iguales.
Tenga en cuenta que, para una buena sal, se supone que la singularidad es a nivel mundial , es decir, que también se aplica a otras aplicaciones que están conectadas a otras bases de datos, que no ' t sabe de La aleatoriedad y / o GUID también se encargan de eso.
Respuesta original que no responde a la pregunta en absoluto:
En el hashing de contraseñas, salt es un "valor único": es decir, cada contraseña obtiene su propio valor de sal. Se genera una nueva sal para cada contraseña. En particular, la sal NO DEBE depender del valor de la contraseña (por lo que no puede ser "computada" a partir de la contraseña), y NO DEBE usarse para más de una contraseña (incluso si el mismo usuario simplemente cambia su propia contraseña, una nueva se generará sal).
Dado que la sal es necesaria para volver a calcular el hash, no hay forma de escaparla: debe almacenar la sal en la base de datos junto con la salida de hash correspondiente. Cuando la sal se almacena con el valor de hash, quienquiera que necesite validar una contraseña lee primero ambos el valor de sal y el valor de hash de la base de datos, luego utiliza el salt y la contraseña para volver a calcular el valor de hash y ver si coincide con el que se acaba de leer de la base de datos.
Las implementaciones deSi la base de datos está compartida, debería poder consultarla antes de agregar un hash. Agregue una restricción única en el campo que contiene la sal, ya que esto evitará que otras aplicaciones reutilicen la sal. Para la generación de sal, refiérase al oso.