Hashing User Passwords lado del servidor o del servidor [duplicado]

En primer lugar, el hash en el lado del cliente generalmente se considera inútil para las aplicaciones web. Cualquier atacante que pudiera pasar por el HTTPS y realizar un ataque MITM también podría cambiar el JavaScript, por lo que enviaría la contraseña en texto sin formato. Por lo tanto, hay poca o ninguna ventaja del hashing en el lado del cliente. La única ventaja posible es que evitaría una falla similar a la que está atravesando Twitter actualmente cuando las contraseñas terminaron accidentalmente en los registros.

Es una historia diferente para aplicaciones nativas. Sin embargo, el hashing simple no aumenta la seguridad considerablemente. Existen enfoques mucho mejores, como el método de autenticación SCRAM . SCRAM permite que la contraseña se oculte en el lado del cliente, sin embargo, el HASH del lado del cliente no se almacena en la base de datos, por lo tanto, un atacante que obtenga acceso a la base de datos del servidor no podrá iniciar sesión con solo el hash almacenado allí.

Comprender el propósito del hash de contraseña en este contexto ayudará a explicar por qué se debe realizar en el servidor y no en el cliente.

La contraseña no está hasheada como para ofuscarla a un adversario que está escuchando la solicitud; esta amenaza en particular debería ser mitigada mediante el uso de HTTPS. En su lugar, el propósito es evitar que la contraseña sea recuperable trivialmente si la base de datos es violada. Si un atacante vuelca una base de datos de contraseñas de texto sin formato, puede leer y usar esas contraseñas inmediatamente (que los usuarios también pueden usar en otros sitios web). Cuando están triturados (y salados), el atacante tiene que hacer más trabajo para forzar a la fuerza bruta la entrada que generó el hash.

Si hash del lado del cliente, el hash se convierte en la contraseña, por lo que no es necesario descifrarlo para acceder al sistema. Un atacante que capture el hash podría simplemente enviarlo como la contraseña y obtener acceso. Sin relación, este tipo de ataque es posible en los sistemas Windows en un ataque de paso-has-hash, donde el compromiso de un hash en un sistema permite que se use para autenticarse frente a otros sistemas.

También, la declaración:

  

(Tengo la impresión de que si utiliza una solicitud POST, los usuarios / atacantes no pueden acceder a los parámetros que se envían al servidor. ¿Está correcto?

es falso. Una solicitud POST no impide el acceso a los parámetros; seguro, no están en la URL como lo estarían los parámetros GET, pero aún son parte del cuerpo de la solicitud. Sin usar HTTPS, un atacante podría ver o modificar los parámetros en cualquier caso.