¿Cómo elegir una sal para una función de hash destinada a proteger las contraseñas?

Question

Soy un principiante (casi completo) y esta es mi primera incursión en el cifrado; de hecho, esta es probablemente la primera vez que uso la palabra.

Aquí está mi pregunta: Para una aplicación web no bancaria/militar, o incluso comercial, ¿cuál es la forma correcta de elegir una sal para una función de hash usada para contraseñas?

Puedo generar fácilmente una sal pseudoaleatoria para cada nuevo usuario y anexar esa sal a su pw antes de aplicar la función hash. Pero aún necesito almacenar la sal, así que, presumiblemente, cualquiera que tenga acceso a las contraseñas hash también obtiene las sales.

¿El beneficio de la sal es simplemente hacer que el pw sea "más aleatorio" y, por lo tanto, anular las tablas de arcoiris basadas en diccionarios estándar?

¿Alguno de los siguientes ser buenos & ideas prácticas:

1. tienda de la sal en una base de datos separada - tal vez un sistema separado, sin duda un host diferente, nombre, PW, etc.
2. generar el sal basado en un hash de un nombre de usuario (o primero + apellido, o fecha de registro), presumiblemente usando una función hash diferente? Entonces, la sal misma no se almacenaría en el DB; solo los datos utilizados para calcularlo ...
3. Almacenar en el db un valor que concatene el hash pw y la sal, de una manera no obvia (p. sal es 10 claves aleatorias, y se inyectan dentro del hash pw entre los números de letra 1 & 2, 4 & 5, 8 & 9, etc.).

Como una pregunta complementaria, ¿qué tan fácil es cambiar un algoritmo hash salado al actualizar el software del sitio web? Se siente una pesadilla en este momento.

Answer 1

1. Hace que el control de las contraseñas sea más difícil - no recomendado.
2. Mejor solo generar un número aleatorio (es probable que sea de 64 bits).
3. Ver (en parte) SO 1191112. La sal no tiene que ser secreta; solo tiene que ser diferente.

Para responder a su pregunta lateral: también guarde un ID de algoritmo (posiblemente un número simple, posiblemente una cadena de nombre) junto con los datos. A medida que realiza la actualización, tiene nuevas contraseñas usando el nuevo algoritmo preferido, pero conserva el antiguo hasta que todos hayan cambiado su contraseña y no haya contraseñas almacenadas con el algoritmo anterior. De nuevo, esto no tiene que ser secreto, solo te permite adaptarte a los cambios en el mundo. Claramente, si el viejo algoritmo se ve de repente como inútil, piense si está bien usar el enfoque incremental. Pero a menos que ocurra algo dramático como ese, implementar el nuevo mecanismo funciona bastante bien. Intente no modificar su algoritmo con tanta frecuencia que tenga tres o más en movimiento a la vez, aunque no hay una razón técnica para que el plan no pueda administrarlo. También intente diseñar su base de datos para que los tamaños de hash puedan crecer sin causar ructions (por lo tanto, deje espacio para la expansión de 64 a 128 bytes, o de 128 a 256, o ...).

Answer 2

Sí, la sal está allí para evitar ataques de arco iris en las contraseñas hash. En general, utilizo un único valor de sal para todas las contraseñas. Está almacenado en mi código fuente o configuración, por lo que no está en la base de datos. Pero probablemente sea mejor usar una sal diferente para cada usuario. De esta forma, dos usuarios con la misma contraseña no obtendrán el mismo hash.

Puede simplemente almacenar la sal en la base de datos junto con la contraseña. El objetivo de la sal es que no se puede calcular previamente una tabla de arco iris. Tomaría demasiado tiempo. Más tiempo que simplemente forzar en bruto la contraseña directamente. Incluso si se conoce la sal, las tablas completas del arco iris para esa sal tendrían que ser generadas, lo cual es extremadamente costoso de hacer. Por lo tanto, no importa mucho si se conoce la sal.

No importa mucho cómo recoja su sal, siempre y cuando se asegure de que sea lo suficientemente larga. Según la Wikipedia, un hash de 12 bits (usado por las viejas contraseñas de Unix) es extremadamente caro de derrotar, pero es posible. 128 bits (como el utilizado por, por ejemplo, MD5) es demasiado caro para defecar en el futuro previsible.

Consulte también: http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables

Answer 3

sales no son un secreto. Se pueden almacenar, en claro, junto con la sal de hash + contraseña. Los hash son salados para evitar ataques de diccionario. Salar con un valor aleatorio almacenado junto con la contraseña o hash el nombre de usuario junto con la contraseña son ambas opciones válidas. Sin embargo, recomendaría un esquema de hash muy específico, es decir, el hash HTTP Digest HA1: user_name : realm : password.Esto tiene el beneficio adicional de poder autenticar las llamadas HTTP Digest, que es la autenticación que se usaría para el acceso automatizado, como una API de programación REST de su sitio.

Antes de que uno salte para condenar el uso de MD5 en lugar de SHA1 (como lo exige el hash del esquema HTTP Digest), pero la colisión de hash MD5 a demanda para el esquema Digest está lejos de ser recurrible en un futuro previsible, y el beneficio adicional del acceso automatizado (piense en WebRequest, curl, etc.) no debe descuidarse.