¿Debo usar el algoritmo MD5 en JavaScript y PHP para la autenticación de inicio de sesión?

Si ignoramos la elección del algoritmo real y consideramos la pregunta: "¿Debo hacer hash tanto en el lado del cliente como del servidor?"

Hashing en Javascript es completamente innecesario, ya que la idea es protegerse contra la contraseña que se detecta durante la transferencia. Pero si eso es un riesgo, entonces la comunicación con el servidor no es segura, lo que significa que ya podría haber un ataque de hombre en el medio.

Esto significa que el atacante podría haber entregado el algoritmo de hashing javascript en lugar del servidor. El algoritmo podría, por ejemplo, enviar la contraseña al atacante.

Entonces, no. No debe utilizar el hash en el navegador, sino utilizar una conexión segura al servidor.

Debe enviar la contraseña al servidor. Si primero toma el MD5 de la contraseña y lo envía al servidor, el MD5 se convierte en la contraseña: si el atacante encuentra el MD5, podría iniciar sesión, sin necesidad de encontrar de qué se trata el MD5.

Por lo tanto, debe asegurarse de que su código Javascript (la parte que se ejecuta en el navegador, es decir, el cliente) lea la contraseña y la envíe al servidor, donde será procesada por el código PHP. Asegúrese de que el campo de entrada de la contraseña esté declarado como una contraseña, de modo que el navegador ofrezca guardarla en su base de datos de contraseñas y no en el historial regular.

Para evitar que un atacante encuentre la contraseña en tránsito o se haga pasar por el servidor, debe usar HTTPS . HTTPS encripta la conexión y le permite al cliente verificar que está hablando con el servidor deseado y no con un imitador que intenta obtener las contraseñas de los usuarios. Además, debe usar HTTPS para transferir cualquier información que dependa de la contraseña: de lo contrario, un atacante podría permitirle al usuario iniciar sesión y luego secuestrar las transmisiones posteriores.

En el lado del servidor, en su código PHP, no use MD5 simple para codificar la contraseña. Las vulnerabilidades que permiten a un atacante obtener la base de datos de contraseñas son muy comunes ( un ejemplo reciente, con un hilo que deberías leer ), así que no pienses que esto nunca te sucederá. Lo más importante es que debe usar un salt , porque tener un salt único para cada contraseña almacenada previene métodos que atacan muchas contraseñas a la vez: esencialmente, cuando las contraseñas se escriben con sal, la única manera de recuperarlos de la base de datos de contraseñas es probando cada posibilidad (fuerza bruta). (Consulte ¿Por qué es más seguro usar sal? para obtener más detalles).

Además, el MD5, aunque no está completamente roto (todavía), tiene muchas debilidades conocidas. No lo uses para nada; use SHA-2 (SHA-256 o SHA-512) en su lugar. Para las contraseñas, esto no es lo ideal, ya que una buena función de hash de contraseñas es lenta : el servidor legítimo no pasa mucho tiempo en la verificación de contraseñas, por lo que puede permitirse que sea lento; pero un atacante que trabaja desde una base de datos de contraseñas pasa todo su tiempo de hashing de las contraseñas, por lo que una desaceleración lo golpeará con fuerza. La recomendación general para el almacenamiento de contraseñas es Bcrypt o PBKDF2 - vea Haga cualquiera ¿Los expertos en seguridad recomiendan bcrypt para el almacenamiento de contraseñas?

El hash en el servidor y el hash en el cliente mitigan diferentes ataques, por lo que uno debe considerar contra qué ataques necesita protegerse.

hashing del lado del servidor

El hash en el servidor mitiga el compromiso de las contraseñas almacenadas (por ejemplo, pérdida de base de datos). Si las contraseñas no se incluyen, un atacante exitoso tendrá acceso inmediato a las credenciales, lo que les permitirá acceder al servidor. Al almacenar contraseñas con hash, el atacante se ve obligado a realizar un esfuerzo adicional para recuperar las credenciales reales.

hashing del lado del cliente

El hash en el cliente mitiga los ataques en el canal entre el cliente y el servidor, así como en los componentes del servidor que procesan las credenciales sin procesar (componente de inicio de sesión, configuración de contraseña y componente de cambio). Al insertar la contraseña en el cliente, el atacante se ve obligado a realizar un esfuerzo adicional para recuperar la contraseña real. Sin embargo, tenga en cuenta que este hash es un texto sin formato equivalente: si un atacante captura el hash, puede usarlo para autenticarse en el servidor.

El valor aquí es proteger la contraseña que ingresó el usuario, ya que la mayoría de los usuarios usan la misma contraseña para otros servicios. Si bien la captura del texto sin formato equivalente pondría en peligro la cuenta del usuario en su servicio, no comprometería las cuentas del usuario en otros servicios. Obviamente, si todos los servicios utilizan este esquema, el mismo hash sería equivalente a un texto simple para otros sitios, por lo que se debe agregar aquí una sal única para el servicio.

Entonces, ¿qué debería hacer uno?

La primera clase de ataques definitivamente debe protegerse, ya que las fugas en la base de datos ocurren, y por lo tanto el hashing del lado del servidor es una necesidad. La segunda clase de ataques se mitiga en gran medida por el uso de TLS, por lo que el esfuerzo adicional para usar hashing del lado del cliente generalmente no vale la pena.

Hashes

Como han dicho otros, se desaconseja el uso de MD5 y SHA1. La familia de hashes SHA2 es segura en sí misma, pero no solo adecuada para el hashing de contraseñas porque están diseñadas para ser rápidas. Las contraseñas deben incluirse en un esquema diseñado específicamente para el hashing de contraseñas, como bcrypt , scrypt o PBKDF2 . Si uno de estos esquemas no es realmente una opción, la contraseña debe incluirse como salpicadura iterativa con un hash SHA2.

Otros enfoques

Hay esquemas como SRP que no almacenan la contraseña o el texto sin formato equivalente en el servidor, ni transmiten la contraseña o texto sin formato equivalente entre el cliente y el servidor.

No debes usar MD5 en absoluto. Se ha resquebrajado de manera efectiva y no sirve para el hashing seguro. Incluso en una computadora normal en estos días, puede generar colisiones MD5 en unos pocos segundos. SHA-1 también es bastante inseguro en estos días (aunque aún un poco más difícil que el MD5, no es demasiado difícil de generar colisiones en cualquiera de las dos), por lo que debería usar [como mínimo] un algoritmo hash basado en SHA-2 (SHA-256 o SHA-512).

Las estrategias de implementación específicas no importan mucho si selecciona un algoritmo hash que puede ser comprometido en minutos por cualquiera que tenga la capacidad de buscar "crackeo MD5" en Google.