PBKDF2 sal fuerte para hashing del lado del cliente

6

¿Qué debo usar como sal segura / fuerte para el hash PBKDF2 cuando no hay sal disponible para usar antes del inicio de sesión, ya que será un javascript del lado del usuario para pasar + pasar el usuario con PBKDF2? Voy a usar sha (usuario + pase) como sal para pbkdf2.

Si uso un salt generado aleatoriamente, debería almacenarlo en la base de datos, pero cuando el usuario quiera iniciar sesión, el usuario no tendrá que guardar el cifrado de su contraseña con salt antes de enviarlo al servidor para su verificación.

Entonces, ¿qué es una solución buena / segura / segura aquí? PD Estoy tratando de lograr el protocolo de "conocimiento cero". También ya estoy usando SSL.

    
pregunta JustACPPFan 11.01.2015 - 02:04
fuente

1 respuesta

7

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
respondido por el Anti-weakpasswords 11.01.2015 - 09:31
fuente

Lea otras preguntas en las etiquetas