¿Existe una ventaja de seguridad para el hashing de una contraseña en el servidor? [duplicar]

No hay seguridad adicional en el hash de la contraseña antes de enviarla al servidor, ya que ahora este hash se convertiría en la contraseña. Lo más importante es enviar la contraseña a través de un canal cifrado (SSL / TLS) para evitar que se envíe en texto sin formato y que otros usuarios de la red lo lean.

Para almacenar la contraseña, debe hash + saltearla, nuevamente para evitar que la contraseña se almacene en texto plano. Si el hash se hubiera realizado en el lado del cliente y usted almacenara este hash, seguiría siendo como si hubiera almacenado la contraseña en texto sin formato, ya que este hash ahora es la contraseña.

Entonces, siempre hash (+ salt) la contraseña en el servidor antes de almacenarla.

Depende del tipo de ataque.

Si el ataque es de tipo intermediario, entonces no tendrá sentido si lo hash nuevamente antes de que llegue al servidor, porque el primer hash ya se había filtrado en su camino.
Si el ataque está en el lado del servidor, sería mejor mantener password => hash => network => hash => database , ya que haría que el proceso de forzamiento de la fuerza bruta más tiempo.
Si el ataque está en el propio cliente (por ejemplo, algún keylogger está instalado en la máquina del cliente), todos estos procesos serían un desperdicio.

En estos días, solo el hashing de la contraseña no es en absoluto confiable . Debería mirar el proceso de salting para hacerlo más confiable y seguro.

Puede utilizar scrypt , bcrypt o PBKDF2 para el hashing y introduciendo sus contraseñas antes de almacenarlas. El hash de contraseña es una actitud de contención de daños . No lo veo útil para rehash dos veces o más. Puede atacar un hash seguro mediante el uso de una rainbow table , que puede evitar aplicando un salt al hash antes de almacenarlo. Le aconsejo que lea esta publicación ( ¿Por qué los hashes salados son más seguros para ¿Almacenamiento de contraseña? ) para obtener información más detallada si está interesado. He leído sobre los sistemas que utilizan este método y sus contraseñas han estado seguras durante 20 años, incluso si los usuarios mantuvieron la misma contraseña a lo largo del tiempo.

Si el hash se envía en texto sin formato, el hash antes del envío es lo mismo que nada; un atacante puede simplemente interceptar el hash y enviar una solicitud falsificada al servidor, otorgándole acceso. Si está utilizando algún tipo de esquema de cifrado (que debería), entonces el hashing dos veces no tiene sentido.

Lo que debe hacer es lo siguiente: cada vez que envía la contraseña al servidor, la envía protegida por una capa de cifrado. Puedes usar HTTPS para ese propósito. Una vez que el texto cifrado llega al servidor, se descifra y se obtiene la contraseña de texto simple. Este procedimiento evita un ataque MitM, un atacante que intercepta la contraseña y la usa para la autenticación. Luego, desea evitar almacenar la contraseña en texto plano, en caso de que la base de datos se vea comprometida en algún momento. Para este propósito, hash la contraseña y la guardas cuando es necesario (en el registro, por ejemplo). Para autenticar, simplemente escriba la contraseña y compare el resumen resultante con el hash almacenado.

Además, puede implementar sales hash para hacer que la tarea de craqueo sea más difícil para aquellos que logran obtener los hashes almacenados en la base de datos.