¿Por qué no es una práctica estándar ejecutar el cliente de KDF basado en contraseña?

Creo que el problema principal son los idiomas del lado del cliente (normalmente JavaScript), son relativamente lentos. Esto a menudo conduciría a menos rondas de hash y, por lo tanto, debilita la seguridad.

Si el idioma del lado del cliente es lo suficientemente rápido, puede calcular el costoso lado del cliente de PBKDF y luego calcular un hash barato en el lado del servidor (por ejemplo, SHA512). Para obtener las contraseñas de texto sin formato, un atacante aún tenía que calcular el PBKDF lento. Tampoco es posible usar el PBKDF directamente como contraseña, ya que solo se almacena el hash del PBKDF (la salida de un PBKDF2 se puede ver como una "contraseña" muy fuerte, por lo que es seguro usar una función hash barata) .

Un inconveniente es que el manejo será más complejo, debe enviar sal y el factor de costo al cliente para verificar la contraseña ingresada. Otro problema es garantizar la integridad del código del lado del cliente, si alguien pudiera alterar el código JavaScript entregado, podría devolver una cadena conocida y usted almacenaría el PBKDF ahora inseguro.

Míralo desde dos extremos: -

1. El servidor está utilizando PBKDF correctamente

   Si el servidor está haciendo PBKDF correctamente, sería una duplicación inútil de esfuerzos y recursos si usted hace lo mismo en el lado del cliente también. Tendrá que implementar o usar un software del lado del cliente que ejecutará PBKDF en su contraseña y luego enviarlo al servidor, y el servidor ejecutará PBKDF en la salida del PBKDF del lado del cliente y almacenará eso en su base de datos. Espero que pueda ver el uso de los recursos adicionales sin ningún beneficio adicional.

2. El servidor no usa PBKDF en absoluto

   Entonces, si el servidor está almacenando contraseñas en texto plano, la salida de su PBKDF del lado del cliente se almacenará tal como está en el servidor. Entonces, cuando un atacante roba la base de datos del servidor, no hará una diferencia si su contraseña fue PBKDFed en el lado del cliente, para el servidor (y el atacante) será exactamente igual que una contraseña de texto simple como hunter1:)

Entonces, para responder a su por qué , el principio general es que es la entidad que controla el recurso que es responsable de su seguridad, que en este caso es el control de acceso. O como un dicho en mi lengua materna, "el hombre sediento tiene que ir al pozo, el pozo no viene al sediento" :)

Un poco de fondo primero:

La razón por la que las contraseñas no se almacenan como texto sin formato por lo general es para proporcionar defensa en profundidad. Es decir, en el caso de un compromiso de la base de datos (que es algo que obviamente debería evitarse), debería evitar que el atacante obtenga acceso a las contraseñas de usuario originales. Esto generalmente hace que obtener acceso a las contraseñas seguras PBKDF2 sea menos valioso para el atacante. Por supuesto, esto solo se aplica cuando las contraseñas son fuertes en sí mismas.

Para responder a tu pregunta:

Si el PBKDF2 se computó en el lado del cliente, una vez que el atacante obtiene acceso a la base de datos, el atacante puede utilizar la salida de PBKDF2 (almacenada en la base de datos) para iniciar sesión como usuarios víctimas a través de la interfaz web. Es decir, el atacante no necesita obtener acceso a la contraseña original para iniciar sesión. El atacante simplemente puede enviar el nombre de usuario y el valor PBKDF2 de la contraseña desconocido al servidor y registrarse como un usuario legítimo. La única diferencia es que el usuario legítimo utiliza JavaScript o algún otro mecanismo del lado del cliente para calcular el valor de PBKDF2 mientras que el atacante lo tendría en la base de datos.

Como resultado, la premisa original de hacer que el acceso a las contraseñas de hash sea menos valioso no se mantiene, ya que el acceso a esa información tiene valor (le da al atacante acceso a la cuenta de los usuarios víctimas). Tiene menos valor para el atacante que obtener acceso a la contraseña original (antes de realizar la operación PBKDF2) pero tiene más valor que si estuviera cifrada en el lado del servidor.

Hay otros problemas con el PBKDF2 del lado del cliente que creo que deberían mencionarse:

• se debería usar una sal estática (es decir, no puede ser aleatoria ya que produciría un valor PBKDF2 diferente)
• otros valores pasados a la función del lado del cliente PBKDF2 del cliente también deberían ser estáticos, por lo que se eliminan varias funciones de seguridad (como cambiar el número de iteraciones)
• al igual que en el caso de PBKDF2 del lado del servidor, la contraseña original se puede recuperar inyectando el código JavaScript para leer las palabras clave o los valores de entrada en el caso de un compromiso de la aplicación web (por ejemplo, XSS y varios otros vectores); de modo que las posibles ganancias de seguridad del PBKDF2 del lado del cliente se pierden