Hashing de contraseñas, sal y almacenamiento de valores hash

Question

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

para crear el valor hash almacenado en el DBMS, tomar:

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

Esto significaría que cualquiera que quiera llegar a una colisión debería realizar el trabajo por separado para cada nombre de usuario y cada instancia del servidor DBMS por separado. Planearía mantener el mecanismo hash actual algo flexible para permitir el uso del nuevo algoritmo hash estándar NIST (SHA-3) que aún se está trabajando.

El 'valor que es exclusivo de la instancia del servidor DBMS' no tiene por qué ser secreto, aunque no se divulgará por casualidad. La intención es garantizar que si alguien usa la misma contraseña en diferentes instancias del servidor DBMS, los valores hash grabados serían diferentes. Del mismo modo, el nombre de usuario no sería secreto, solo la contraseña propiamente dicha.

¿Sería una ventaja tener primero la contraseña 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é tal entrelazar las cuerdas?

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

un buen montón de preguntas relacionadas con SO - esta lista es poco probable que sea integral:

• Encrypting/Hashing plain text passwords in database
• Secure hash and salt for PHP passwords
• The necessity of hiding the salt for a hash
• Clients-side MD5 hash with time salt
• Simple password encryption
• Salt generation and Open Source software
• Password hashes: fixed-length binary fields or single string field?

creo que las respuestas a estas preguntas apoyan mi algoritmo (aunque si usted sólo tiene que utilizar una sal de azar, entonces el "valor único para cada servidor y los componentes de nombre de usuario son menos importantes).

Answer 1

La sal solo tiene que ser aleatoria y única. Se puede conocer libremente ya que no ayuda a un atacante. Muchos sistemas almacenarán la sal de texto sin formato en la base de datos en la columna junto a la contraseña hash.

La sal ayuda a garantizar que si dos personas (usuario A y usuario B) comparten la misma contraseña no es obvio. Sin la sal aleatoria y única para cada contraseña, los valores de hash serían los mismos y, obviamente, si la contraseña para el usuario A se descifra, entonces el usuario B debe tener la misma contraseña.

También ayuda a proteger contra ataques donde un diccionario de valores hash se puede comparar con contraseñas conocidas. p.ej. mesas de arcoiris.

También el uso de un algoritmo con un "factor de trabajo" incorporado también significa que a medida que la potencia de cálculo aumenta el trabajo que un algoritmo tiene que pasar para crear el hash también se puede aumentar. Por ejemplo, bcrypt. Esto significa que la economía de los ataques de fuerza bruta se vuelve insostenible. Presumiblemente, se vuelve mucho más difícil crear tablas de hashes conocidos porque tardan más en crearse; las variaciones en "factor de trabajo" significarán que se deben construir más tablas.

Answer 2

¿Por qué no agregar una sal al azar a la contraseña y hash esa combinación? Luego concatene el hash y la sal a un solo byte [] y almacénelo en el db?

La ventaja de una sal al azar es que el usuario puede cambiar su nombre de usuario.The Salt no tiene que ser secreto, ya que se usa para evitar ataques de diccionario.

Answer 3

Creo que está complicando demasiado el problema.

de inicio con el problema:

1. ¿Estás tratando de proteger las contraseñas débiles?
2. ¿Estás tratando de mitigar los ataques del arco iris?

El mecanismo que propone protege contra un simple ataque de arco iris, porque incluso si el usuario A y el usuario B tienen la MISMA contraseña, la contraseña de hash será diferente. Sí, parece un método bastante elaborado para salar una contraseña que es demasiado complicada.

• ¿Qué sucede cuando migra la base de datos a otro servidor?
  • Puede cambiar el valor único, por valor de base, si es así, se puede generar una tabla global de arcoíris, si no, no puede restaurar su base de datos.

En vez me acaba de añadir la columna extra y almacenar una sal adecuada al azar. Esto protegería contra cualquier tipo de ataque del arco iris. En múltiples implementaciones.

Sin embargo, no lo protegerá contra un ataque de fuerza bruta. Por lo tanto, si intenta proteger a los usuarios que tienen contraseñas molestas, deberá buscar en otra parte. Por ejemplo, si sus usuarios tienen contraseñas de 4 letras, probablemente podría descifrarse en segundos incluso con un salt y el algoritmo hash más nuevo.

Answer 4

Creo que debes preguntarte "¿Qué esperas ganar haciendo esto más complicado que simplemente generar un valor aleatorio de sal y almacenarlo?" Cuanto más complicado sea el algoritmo, más probable es que introduzca una debilidad inadvertidamente. Esto probablemente suene sarcástico, no importa cómo lo diga, pero tiene un significado útil: ¿qué tiene de especial la aplicación que necesita un nuevo y sofisticado algoritmo hash de contraseñas?