¿El hashing de contraseña en el frontend o en el backend? [duplicar]

@John ya describió muy bien el paso de la contraseña a través de la red (use HTTPS).

Para responder a su pregunta:

  

¿Dónde debería hacerles hash? Frontend o Backend?

El backend . Si solo los hash en la interfaz, eres vulnerable a un pase del ataque hash.

La razón por la que hash las contraseñas en tu base de datos es para evitar que un atacante que ya ha comprometido tu base de datos use esas contraseñas.

Si hash las contraseñas en el backend, un atacante primero tiene que descifrarlas para usarlas en tu sitio web. pero si los hash en la interfaz, un atacante no necesita hacer esto, solo pueden pasar el hash tal como está almacenado en la base de datos.

El hash frontend protege la parte de los usuarios que reutilizan las contraseñas en diferentes sitios web de aquellas cuentas que también están en riesgo, por lo que es una buena adición al hashing backend, pero no es una alternativa (tampoco es una alternativa). a HTTPS; si su certificado se agota, debe renovarlo, el hash frontend no lo ayudará aquí).

Estás confundiendo dos cosas: la seguridad del transporte y la seguridad de la base de datos. HTTPS utilizando TLS solo protege el transporte de datos del cliente al servidor. Esto significa que un intruso no sabe qué cliente y servidor se están enviando (simplificado). El almacenamiento de contraseñas es un tema completamente diferente. Desea asegurarse de que, incluso si un atacante obtiene acceso a su base de datos, no puede acceder a las contraseñas de texto sin formato.

No importa cómo almacene las contraseñas, siempre debe usar TLS. De lo contrario, un intruso puede registrar lo que el cliente envía al servidor para autenticarse. Entonces, no importará si realiza la HASHING de contraseñas en el lado del cliente o del lado del servidor. El atacante podría simplemente grabar lo que pasa por el cable y volver a reproducir la comunicación para obtener acceso, haciéndose pasar por el cliente.

(Tenga en cuenta que desea realizar el procesamiento de contraseñas, no el cifrado. El hash es unidireccional, el cifrado no lo es)

El hashing se debe hacer en el back-end. El back-end está bajo su control, por lo que puede hacer cumplir el hash como se debe. Además, puede tener hashing del lado del cliente. No debe utilizar el hashing del lado del cliente solo, como lo haría el proceso, por ejemplo. Se hará en JavaScript que el usuario podría bloquear o manipular. Puede que no parezca una amenaza razonable, pero nunca debe confiar en ningún dato proporcionado por el usuario. Por lo tanto, no debe asumir que el cliente está haciendo el hashing correctamente. Esto implica que definitivamente tienes que hacerlo en el back-end.

HTTPS proporciona seguridad solo para la capa de transporte. No tiene nada que ver con los mecanismos de seguridad necesarios para el almacenamiento.

No debes criptar contraseñas. Debería hacerlos hash, por lo que no podría descifrarlos más tarde (ni a un atacante).

Y el paso hash siempre se realiza en el backend, ya que hacerlo en el lado del cliente le permitiría a un atacante que tenga acceso a sus hashes un método para iniciar sesión en cada cuenta.

HTTPS (HTTP sobre TLS / SSL) proporciona seguridad sobre los datos en tránsito / datos en movimiento, NO proporciona cifrado en los datos en reposo (Base de datos, archivos en un disco duro) - > Encriptados con AES, 3DES, BlowFish, etc.

Puede proporcionar cifrado en la base de datos, pero no en toda la base de datos, ya que esto consumirá sus recursos (los archivos cifrados son más grandes que los no cifrados). Solo encripta un campo específico, es decir, PII del cliente - > Información de la tarjeta de crédito.

No es una práctica recomendada cifrar las contraseñas de los usuarios, solo HASH y SALT.

Cuando su certificado HTTPS caduque, está bien que el atacante pueda rastrear las contraseñas en texto sin formato, solo proporcione la capa de seguridad en su código.

Cuando el usuario proporciona la contraseña, su código debe tener un procedimiento almacenado (SQL) que coincida con el valor HASHED + SALT de la contraseña del usuario en su base de datos. Si el valor HASH + SALT no coincide, obviamente es una contraseña incorrecta.

Nota: Hashes proporcionan integridad.

La función SALT mitigará el riesgo de que el atacante ejecute un ataque de tabla arco iris, porque el atacante no conoce el valor SALT.

La clave: HASH + SALT

enlace