¿Es una buena idea usar una entrada del usuario como SALT?

Quieres que la sal sea única. Tampoco desea que la sal sea "reveladora" porque la almacenará "como está", como texto claro, en el servidor de la base de datos. Una sal no debe ser secreta, pero la gente puede ponerse nerviosa si almacena, desprotegida, algún valor que sienten debería ser secreto, y esto incluye el apellido de soltera de su madre, que aparentemente es usado por algunos Los bancos estadounidenses como mecanismo de autenticación.

Asegurar la exclusividad de las sales es fácil en el lado del servidor: simplemente genere una secuencia suficientemente larga de bytes aleatorios. La aleatoriedad no es singularidad , pero funciona igual de bien con una probabilidad abrumadora. Las buenas funciones de hashing de contraseñas pueden usar cualquier secuencia de bytes como sal . Las buenas implementaciones de las funciones de hashing de contraseñas incluso generarán el salt de forma adecuada para usted, y lo incluirán en su salida, por lo que no tiene que preocuparse por eso (eso es lo que normalmente ocurre con bcrypt ); en ese caso, olvídese de esta respuesta y de su pregunta y deje que la biblioteca haga su trabajo.

Pedirle al usuario que responda a su propia sal es una mala idea. Primero, es técnico, y se puede asumir que la mayoría de los usuarios no comprenden nada de lo que es una sal; Muchos de ellos se pondrán nerviosos. Además, cuando los usuarios hacen entienden qué es una sal, entonces saben que una buena sal es una sal aleatoria; los usuarios humanos no están bien equipados para generar aleatoriedad (no es parte de lo que un cerebro humano es bueno). Por otro lado, su servidor puede hacer aleatoriedad. Finalmente, no puede contar con usuarios humanos para imponer la singularidad, y, en particular, cuando un usuario cambia su contraseña , no cambia su nombre de soltera de la madre , por lo que es un fracaso inevitable en la singularidad.

Edite: si su lenguaje de programación ofrece UUID , también conocido como GUID (la distinción es Bizantina), entonces estas son buenas para las sales. Por ejemplo, en .NET, simplemente llame a System.Guid.NewGuid() . Existen varios métodos para crear tales valores, pero todos apuntan a la singularidad mundial (pueden ser predecibles, pero eso no es un problema para las sales). "Método 4" es en realidad 122 bits de aleatoriedad. El mejor método para la generación de sal es permitir que el código de la biblioteca de hashing de contraseña lo haga, pero si tiene que usar una biblioteca que no lo hace por sí misma, entonces usar un UUID proporcionado por el sistema es un método decente de bajo esfuerzo.

Una sal se usa para ayudar a prevenir el uso de tablas de arco iris y requiere que un atacante ataque cada hash por separado. Esto solo funciona si no es posible hacer tablas de arco iris para todo el espacio de sales.

Una sal elegida por el usuario es a) muy probable que no sea única, incluso localmente yb) altamente probable que sea un valor que pueda encontrarse en una base de datos de tabla de arco iris en comparación con una elegida al azar. Ambos dan como resultado una gran reducción en la efectividad de la sal, ya que simplifican los ataques contra el hash.

Si bien la sal no tiene que ser aleatoria, sí tiene que ser globalmente única para que no se pueda usar una base de datos de tablas de arco iris. La aleatoriedad es la forma más fácil de garantizar esto, aunque otras opciones viables para obtener una sal sí funcionan.

No hay ninguna razón para utilizar una entrada de usuario, está perfectamente bien simplemente usar un número aleatorio y almacenarlo en la base de datos con el registro del usuario. Esto no afecta negativamente a la seguridad, ya que la sal no tiene que ser única, solo tiene que hacer inviables las tablas de arco iris precalculadas.

Como dijo Terry en su respuesta, el único requisito para un salt es ser único para cada contraseña. Por lo tanto, solo generaría un bytest aleatorio de al menos 16 bytes de largo (asegúrate de usar el generador aleatorio de tu sistema operativo y no una implementación extravagante de bricolaje). El apellido de soltera de su madre puede ser algo que realmente es probable (no hay tantos nombres diferentes, tal vez solo mil) que vuelva a ocurrir, es más improbable que genere los bytes aleatorios.

Recuerde que se le permite almacenar el texto sin formato de sal junto a la contraseña, una sal no se considera secreta.

El único requisito de una sal es que sea única a nivel mundial. Si está seguro de poder cumplir con este requisito, siga adelante.

Piensa en esto, sin embargo, ¿qué ofrece exactamente tu esquema propuesto sobre el método estándar existente para capturar algunos bytes de datos aleatorios? ¿Por qué quieres mear a tus usuarios pidiendo otra entrada? No agregue más complejidad para usted y para sus usuarios. Manténgase al tanto del método estándar, que generalmente se encarga automáticamente con cualquier biblioteca de hashing de contraseñas decentes.

No hay razón para no hacer una sal al azar. No necesariamente se necesitan números aleatorios criptográficamente sólidos, solo algunos bits de un PRNG que se siembra con un momento del día de alta resolución y algunos otros valores como la identificación del proceso y otras cosas.

Agregar preguntas para obtener información adicional del perfil con el único fin de crear un Salt parece una idea pobre desde la perspectiva de la experiencia y la eficiencia del usuario.

Si va a crear la sal mediante el hash de información de perfil de usuario, use los valores de las propiedades que ya están allí. Pero, volviendo al primer punto: incluso si usa esa información, no hay razón para no mezclar variables adicionales no relacionadas con el perfil del usuario, como la porción de microsegundos de la hora del día.

  

Re: La probabilidad de que exista exactamente el mismo nombre en nuestra fuerte comunidad de 2000 es extremadamente baja.

¿Has oído hablar de la paradoja de cumpleaños ? Las probabilidades de que alguien de un total de 2000 personas tengan un apellido en particular son más pequeñas que las dos personas en una multitud de 2000 que tienen el mismo apellido.