¿se mejoró bcrypt con la frase de contraseña hmac'd?

Question

dado:

$ sal - una cadena generada pseudo-aleatoria de longitud suficiente

$ pimienta - una suficientemente fuerte clave privada, conocida sólo por los administradores de la db donde se almacenan las frases de contraseña

verías

$ = hash de bcrypt (HMAC ($ userpassphrase, $ pimienta), $ sal)

siendo significativamente superior a

$ hash = bcrypt ($ userpassphrase, $ salt)

teniendo en cuenta la carga adicional de administrar/almacenar $ pimienta y $ sal?

mi suposición es que el hmac no fortalece de manera significativa el $ hash resultante, y la carga de almacenar $ pimienta supera cualquier supuesto beneficio ... pero me encantaría escuchar opiniones informadas.

Answer 1

Los hashes con clave, o HMacs, están destinados a verificar el origen de los datos y no a la protección por contraseña. Por ejemplo, si usted y yo tuviéramos una clave compartida, podríamos enviarle algunos datos junto con el hmac computado, y podría usar esa misma clave para verificar si los hashes de hmac coinciden, y si es así, usted sabe que los datos provienen de yo, y no ha sido alterado.

No hay manera de que ocultes eficazmente una contraseña secreta en la máquina a la que un atacante no podría acceder, todo lo que harías es agregar una capa de oscuridad. Usar un HMac, sin tener una clave secreta compartida, es esencialmente lo mismo que hacer SHA ($ userpassphrase, $ salt), que es muy fácil de calcular, y por lo tanto no agregaría ninguna seguridad significativa a su esquema de hashing de contraseña una vez que el "secreto "contraseña es conocida.

El objetivo de bcrypt es simplemente ralentizar el proceso de hash, por lo que a un atacante le llevaría mucho tiempo generar una tabla de arcoiris para su sal. Si desea hacer su esquema de hash de contraseña más seguro, simplemente aumente el costo de la función de hashing original. En bcrypt, puede especificar el número de "logRounds" (creo que así es como lo llamaron), que es el número de veces que se realiza el hash. Si especifica un logRounds de 15 (10 es el valor predeterminado), el hash se realizará 2^15 = 32768 veces, lo que ralentiza significativamente. Cuanto más tiempo lleve realizar el hash, más tiempo le tomará a un atacante romperlo.

Answer 2

No estoy seguro de cómo te gustaría usarlo. Suponiendo que almacene $ hash para hacer una autenticación de desafío-respuesta más tarde, entonces necesitaría obtener $ pimienta para el cliente y sería simplemente otra sal. Simplemente agregar un HMAC no será de mucha utilidad.

Answer 3

No tiene sentido agregar un hash extra a una función de extensión de contraseñas como bcrypt; sería más fácil y mejor repetirlo un par de veces más.

El 'pimiento' es una práctica común pero cuestionable; Personalmente soy de la opinión de que los modelos de ataque bajo los cuales un atacante obtiene su base de datos pero no tiene acceso a su clave secreta están lo suficientemente ideados como para que la protección contra ellos no valga la complejidad de implementación que resulta.