epixoip/hmac-bcryptThe hmac-bcrypt password hashing function
Este repositorio contiene implementaciones de referencia de la función de hash de contraseñas hmac-bcrypt en varios lenguajes. Cada implementación de referencia intenta ser un puerto 1:1 de las implementaciones originales en C y Perl creadas por @epixoip cuando es posible, y son totalmente compatibles entre sí (es decir, producen y validan los mismos valores hash).
Cada implementación de referencia define dos funciones procedimentales con los siguientes pseudoprototipos:
string hmac_bcrypt_hash(password, settings?, pepper?)
boolean hmac_bcrypt_verify(password, expected, pepper?)
Consulte los casos de prueba proporcionados con cada implementación de referencia para saber cómo integrar y utilizar estas funciones en su proyecto. Se eligió una interfaz procedimental por simplicidad, pero usted es libre de incorporar estas funciones en clases u objetos como desee.
El parámetro settings en este contexto se refiere a una cadena de configuración bcrypt estándar que contiene el identificador de hash (2a), el costo log2 (p. ej., 13) y un valor de sal opcional de 22 bytes codificado en radix64 (p. ej., LhayLxezLhK1LhWvKxCyLO). Estos valores se concatenan en una cadena delimitada por signos de dólar; p. ej., $2a$13$LhayLxezLhK1LhWvKxCyLO.
El parámetro settings es opcional; en la mayoría de los casos, debe dejarse nulo/vacío para usar el costo predeterminado de 13 y una sal generada. Como máximo, si desea usar un valor de costo distinto de 13, puede proporcionar solo el id + valor de costo (p. ej., $2a$10$). No se recomienda crear y proporcionar sus propios valores de sal.
El parámetro pepper define un secreto compartido global y también es opcional; si es nulo/vacío, se usa el valor predeterminado de hmac_bcrypt. Esto es principalmente para la defensa contra ataques shucking, pero también se puede usar para aumentar la seguridad, la dificultad y el costo de crackeo (especialmente cuando se usa junto con un HSM).
La función de hash de contraseñas hmac-bcrypt emplea bcrypt con pre-hash y post-hash adecuados, combinados con un pepper opcional. En pseudocódigo, esto es bastante sencillo:
pre_hash = hmac_sha512_base64(password, pepper)
mid_hash = bcrypt(pre_hash, settings)
post_hash = hmac_sha512_base64(mid_hash, pepper)
return settings + post_hash
El pre-hash se emplea para permitir longitudes de entrada mayores que el máximo de bcrypt de 72 bytes de entrada. Se eligió SHA-512 debido a su tamaño de palabra de 64 bits, que es amigable para los defensores en CPU pero dificulta a los atacantes en GPU. Sin embargo, un valor SHA-512 sin procesar no se puede usar por varias razones:
Para mitigar los ataques shucking, el pre-hash debe ser salado -- o en este caso, con pimienta (peppered) -- y HMAC proporciona un vehículo conveniente para aplicar clave a un hash. El valor HMAC resultante se codifica luego con base64 para producir una entrada limpia en ASCII inferior que mitiga los problemas con bytes nulos y datos binarios.
El lector perspicaz notará que hmac_sha512_base64 produce 88 bytes de datos, mientras que bcrypt tiene un tamaño máximo de entrada de 72 bytes. Esto no es un problema; de hecho, es preferible a utilizar un algoritmo de hash que produzca menos datos de entrada, como sha256. Queremos llenar los 72 bytes completos, y no se pierde seguridad al truncar sha512 a 432 bits (que es mayor que los 384 bits que proporciona sha384).
El post-hash se emplea principalmente para diferenciar los hashes hmac-bcrypt de los hashes bcrypt -- es decir, las longitudes serán diferentes -- pero también para añadir una capa extra de protección gracias al pepper. El paso de post-hash incluso podría realizarse con el valor de pepper almacenado en un HSM (¡muy recomendable!) para mayor protección.
Si bien la dureza de memoria (memory hardness) ha sido un experimento interesante, el camino correcto para lograr resistencia a la aceleración es claramente la dureza de caché (cache hardness). Las velocidades y el ancho de banda de la memoria continúan aumentando, mientras que la RAM se vuelve más grande, más barata y más densa. Pero los tamaños de caché, las velocidades de caché y los costos de caché son relativamente estáticos. Incluso las instrucciones de hardware scatter/gather no han tenido el impacto dramático que alguna vez predijimos que podrían tener en los algoritmos duros de caché.
Los mejores algoritmos de dureza de memoria -- Argon2 y scrypt -- son en realidad menos resistentes a la aceleración que los algoritmos de dureza de caché para tiempos de ejecución objetivo inferiores a 1000 ms, lo que los convierte en excelentes KDF pero no muy buenos para la autenticación en tiempo real.
Idealmente, se usaría una función de hash de contraseñas intencionalmente duro de caché, como pufferfish o bscrypt. Sin embargo, estas funciones son más nuevas, menos estudiadas y tienen pocas bibliotecas disponibles. bcrypt, en cambio -- aunque involuntariamente duro de caché -- está fácilmente disponible para prácticamente todos los lenguajes y frameworks. De los algoritmos que tenemos fácilmente disponibles, bcrypt ofrece la mayor resistencia a la aceleración para la autenticación interactiva en tiempo real (tiempo de ejecución objetivo < 1000 ms), por lo que la respuesta obvia entonces es aprovechar el bcrypt que tenemos disponible.
Sin embargo, bcrypt tiene algunas limitaciones notables, como sus críticos más vocales se apresuran a señalar:
hmac-bcrypt aborda ambos problemas, y más.