Esto creo que puede ser una pregunta tonta, pero me he confundido bastante sobre lo que debería hacer aquí para lo mejor.¿Debe la sal para una contraseña Hash ser "hash" también?
Al salar una contraseà ± a de contraseà ± a, ¿la sal tambià © n debe reducirse o dejarse como texto sin formato?
NOTA: Estoy ingresando una contraseña en SHA-256 y Salt es una cadena predefinida ya que solo se almacenará una contraseña a la vez.
TIA
Chris (Shamballa).
No importa.
El propósito de una sal es evitar ataques de precálculo.
De cualquier manera, hashing la sal o usándola solo, da como resultado la misma información que se agrega como sal cada vez. Si usas la sal, lo único que estás haciendo es cambiar la sal. Al mezclarlo primero, lo convierte en una cadena diferente, que luego se usa como sal. No hay ninguna razón para hacer esto, pero no hará nada malo si lo hace.
Solo necesita ser consistente y usar el mismo método cada vez o terminará con un hash de contraseñas diferente.
La sal no debe ser hash, ya que necesita el valor original para combinar con la contraseña antes de hash.
No debe hash la sal, ya que los hashes son de una sola dirección. Necesitas la sal para poder agregarla a la contraseña antes de hash. Puedes encriptarlo, pero no es necesario.
Lo crítico de sales es que cada contraseña debe tener su propia sal. Idealmente, cada sal debe ser única, pero al azar también es buena. Por lo tanto, la sal debe ser lo suficientemente larga como para permitir que sea única para cada contraseña.
Si todas las sales son iguales, es obvio para el cracker (que puede ver sus valores de hash), cuyas cuentas tienen la misma contraseña. Los valores hash serán los mismos. Esto significa que si descifran una contraseña, obtienen más de una cuenta sin trabajo adicional. El cracker incluso podría apuntar a esas cuentas.
Debería suponer que el cracker obtendrá tanto el valor de sal como el de hash, por lo que el algoritmo hash debe ser seguro.
Tener cualquier sal impide el uso de tablas existentes de arcoiris precalculadas para descifrar el valor de hash, y tener una sal única para cada cuenta elimina el deseo de que su cracker precalcular sus propias tablas de arco iris con su sal.
@aaaa bbbb, si hash la sal antes de almacenarla, no puedes recuperar la contraseña. Si usas un algoritmo hash en tu generación de la sal, está bien. La sal es la parte que se agrega al texto claro justo antes de calcular el valor. No es una sal antes de eso. –
No, no debe hash la sal. La sal está en texto sin cifrar y se necesita para volver a calcular la contraseña y verificarla con la almacenada en el archivo de contraseña hash.
Pero si necesita un fuerte proceso de salado se puede calcular su contraseña con sal de esta manera:
SaltedHashedPwd = H (H (H (H (H ..... (PWD-k + SAL-k) + SALT-k) + SALT-k) .....) + SAL-k + N
H es la función hash SAL-K es una cadena k-aleatoria se utiliza en forma de sal PWD-k es el k-contraseña (cada contraseña tiene una sal diferente) N es el número de iteraciones que usted compone la función H
¡En el estándar PKCS # 5 usa N = 1000!
En este manne, un ataque de diccionario no es posible porque para cada palabra en el diccionario y para cada SAL en el archivo de contraseñas, el atacante debe calcular el hash. Demasiado expansivo en el tiempo!
creo que N = 100 debería ser suficiente para sus usos :-)
Incorrecto. "No importa" es la respuesta correcta. Puede picar la sal, que en efecto le da una nueva sal que funciona. Todo lo que tienes que hacer es ser consistente. –
Vea mejor lo que escribí. Puede tener la concatenación de PWD y SALT pero al final debe concatenar la forma clara de SALT. De lo contrario, no puede volver a calcular el hash en la fase de verificación. – robob
como las necesidades de la sal que se guardan junto con el hash (o por lo menos debe ser recuperable, junto con el hash), un atacante podría posiblemente obtenga tanto la contraseña de sal como la de hash. En algunas de mis aplicaciones, he almacenado el encriptado en la base de datos (con una clave conocida solo por la aplicación). Mi razonamiento era que almacenar la sal sin cifrar junto con la contraseña hash facilitaría descifrar las contraseñas, ya que un pirata informático que podría recuperar la tabla de contraseñas (y sabría o haría una suposición sobre el algoritmo hash) sería capaz de para encontrar coincidencias entre hashes de palabras bien conocidas (ataque de diccionario) al mezclar cada palabra en el diccionario y luego salar con la sal a la que también tiene acceso. Si la sal se encriptara, tal ataque no sería posible a menos que también tuviera acceso a la clave de encriptación conocida por la aplicación.
(Si alguien ve un error en esta lógica, por favor coméntelo.)
Todavía recomendaría fuertemente no utilizar una sal estática. Probablemente derrota el propósito de tener una sal, incluso si solo almacena una contraseña a la vez. – Slartibartfast
Estoy de acuerdo, probablemente se deba usar una sal diferente para cada contraseña, solo necesita usar la misma sal cada vez para la contraseña de un usuario dado. Pero el punto aquí fue que una sal es solo algo extra añadido. Pasar la sal antes de usarla no cambia eso, solo hace que sea algo extra diferente. –
Es semántica, pero no debe hash una sal. Una sal debe ser recuperable en texto claro para ser utilizada. Como un hash es de una sola manera, no debes poner hash tu sal. Si desea utilizar un algoritmo hash para generar su sal, está bien, pero el valor hash resultante se convierte en el nuevo sal y aún debe poder recuperarlo en texto claro. Si realmente has criticado tu sal, has perdido tu cuenta. –