Primero, asegúrese de leer esta respuesta a la pregunta "Hash de contraseña del lado del cliente" , prestando especial atención hasta el último párrafo.
Además, tenga en cuenta que el JavaScript del lado del cliente será increíblemente lento en PBKDF2 en comparación con el buen código del lado del servidor. Al menos intente encontrar una implementación PBKDF2 que use HMAC-SHA-512 como base.
Dicho esto, si quieres darle tranquilidad al usuario, está bien; haga lo siguiente:
- hash PBKDF2 del lado del cliente para un recuento de iteración "alto" conocido.
- ¡Doble puntos de bonificación si el usuario puede seleccionar el recuento de iteración!
- Pongo muchas citas porque dudo que su código javascript sea lo suficientemente rápido para hacer decenas o cientos de miles de iteraciones en el tiempo en que pueda obtener suficiente de su base de usuarios para aceptar, especialmente en dispositivos móviles más baratos. li>
- Un buen hash del nombre de usuario y la contraseña como un salt no es bueno, aunque es mejor si su código coloca el nombre de usuario en la longitud máxima posible y lo coloca primero.
- De esa manera, "user1" y "password" no hacen el mismo salt que "user" y "1password"!
- Por supuesto, no hay una longitud máxima en la contraseña, excepto la causada por el software de back-end; SQL Server, por ejemplo, tiene un máximo de 8000 bytes en el trabajo de cadena "menos ineficiente".
- Envía ese hash al servidor
- que luego genera un sal criptográficamente aleatoria de 12-16 bytes
- y luego usa PBKDF2 con un recuento de iteración mucho más alto para el hash del hash pasado
- nuevamente, espero que HMAC-SHA-512 para las operaciones de 64 bits disminuya la ventaja proporcional de los ataques de GPU sin conexión.
- porque entonces alguien que obtiene su base de datos de contraseñas filtrada todavía tiene que hacer el trabajo de un ataque contra una función de hash de contraseñas para iniciar sesión, en lugar de simplemente enviar el hash generado por el cliente que robaron y que se lo acepte tal como está.
Recuerde, especialmente con el hash de contraseña PBKDF2, nunca solicite un tamaño de salida mayor que el tamaño de salida del hash base nativo. Más pequeño está bien si está realmente preocupado por el almacenamiento; por ejemplo, solicitando solo 32 bytes de la salida nativa de 64 bytes de PBKDF2-HMAC-SHA-512.
- 20 bytes para SHA-1
- 32 bytes para SHA-256
- 64 bytes para SHA-512