¿Establecer un hash, iniciar sesión con una contraseña?

Estoy de acuerdo con @Xiong Chiamiov, no hay nada intrínsecamente incorrecto con este enfoque.

Por otro lado, no proporciona mucho beneficio al enfoque estándar (todo hash se realiza en el lado del servidor), y definitivamente existe cierto riesgo en la divulgación del hash a entidades no confiables.

Si el cliente original no es de confianza, esto obviamente no hace nada, ya que el cliente podría simplemente registrar la contraseña ingresada.

Si la conexión original entre el cliente y el servidor no es confiable, esto solo ayuda un poco. Un hombre pasivo en el medio todavía ganó el hachís y puede intentar romperlo. Un hombre activo en el medio podría cambiar el hash para obtener acceso, o podría cambiar la respuesta a la política de hash para forzar a un hash débil a obtener la contraseña (o no forzar el hash en absoluto, o simplemente inyectar Javascript o algo similar para leer el contraseña ingresada).

Por lo tanto, el único caso de uso razonable es la mitigación limitada contra un hombre pasivo en el medio en el registro inicial. Si me encontrara con esto, comprobaría qué tan poco confiable es realmente el registro inicial, y si no hay un enfoque más sensato que revelar el hash.

El problema que generalmente surge cuando se habla de hashing del lado del cliente es que un atacante que ha violado el la base de datos simplemente puede pasar los hashes al servidor para autenticarse. Sin embargo, este esquema no permite el uso del hash para la autenticación, solo la creación inicial de la cuenta, por lo que no cae en esa trampa.

He visto este tipo de cosas utilizadas en el contexto de los archivos htpasswd de Apache; los usuarios generan un resumen y lo envían en un canal relativamente inseguro (por ejemplo, correo electrónico) al administrador de sistemas, que luego lo agrega a la configuración del servidor. Si bien un sistema con autenticación básica o de resumen no es el pináculo de la seguridad informática, esto demuestra que no es un enfoque completamente novedoso, y ha tenido al menos algo de atención.

Dada la descripción tal como la colocas, no veo ningún problema obvio. Por supuesto, puede haber problemas de implementación, como un error que permite alimentar el hash en lugar de la contraseña para la autenticación. Y como la conexión inicial no es confiable, es probable que sea más fácil para un atacante obtener un hash de contraseña (que luego pueden intentar descifrar o generar una colisión). Pero esos no son problemas con el esquema en sí, o problemas importantes.

Dos liendres

  

posiblemente después de solicitar la política de hash - sal, qué función de hash, etc. - del servidor

No estoy claro si este mecanismo utiliza una sal por usuario o una sal global. Si usa una sal global, es vulnerable a un ataque de arco iris.

  

El servidor almacena "99476bb ..." en la base de datos como el hash de contraseña para ese usuario.

Debido a que el hash se generó fuera del servidor, no hay forma de que el servidor imponga ninguna complejidad de contraseña o reglas de longitud. Tendrían que ser aplicados por la aplicación. Además, no hay forma de verificar la reutilización de la contraseña.

No creo que el esquema propuesto agregue ningún riesgo adicional, pero tampoco estoy seguro de que realmente esté reduciendo. Parece que falta un poco de información crucial. Bajo este esquema, ¿cómo vetarás inicialmente al cliente para saber que son quienes crees que son antes de permitirles establecer el hash? Este es el verdadero desafío: hay varias formas diferentes en que puede comunicar un conjunto / cambio de contraseña a través del cable para evitar ataques MitM, pero cuando desea permitir la configuración remota de cualquier tipo de proceso de autenticación, el problema está en examinar la usuario remoto.

Tampoco estoy convencido de que la política que está causando que usted tenga que considerar esta alternativa tenga un beneficio real, excepto para que los auditores se sientan mejor. Afrontémoslo, si su riesgo es recopilar información de contraseña de la memoria del sistema operativo, el problema real son los controles adecuados sobre el acceso al sistema operativo y esa memoria, no a lo que hay en la memoria. Si alguien tiene ese nivel de acceso, entonces es probable que puedan comprometer su proceso de autenticación base de todos modos. Lo que realmente está haciendo la política es agregar complejidad, lo que probablemente creará otros problemas.