Generador y verificador de hash bcrypt

Acerca de esta herramienta

Por qué bcrypt es lento a propósito

Las bases de datos de contraseñas se roban, y quien tiene una puede intentar adivinar contraseñas sin conexión, tan rápido como le permita su hardware. Los hashes de uso general como SHA-256 están hechos para ser rápidos, así que una sola tarjeta gráfica prueba miles de millones de candidatas por segundo. bcrypt, publicado por Niels Provos y David Mazières en 1999, se basa en la costosa expansión de clave del cifrado Blowfish y la repite un número configurable de veces, lo que encarece cada intento.

Cada hash lleva además su propia sal aleatoria de 16 bytes. Dos usuarios con la misma contraseña obtienen hashes distintos, y una tabla precalculada para una sal no sirve para la siguiente. Un hash bcrypt no se puede descifrar. El ataque práctico es adivinar, así que una contraseña débil cae rápido sea cual sea el costo.

Qué significa el costo y cómo elegirlo

El costo es el logaritmo en base 2 del número de rondas de expansión de clave: costo 10 son 1024 rondas, costo 12 son 4096. Sumar uno duplica el tiempo de un inicio de sesión y de cada intento de un atacante. El costo queda escrito en el hash, así que puedes subirlo más adelante: los hashes antiguos se siguen verificando, y puedes volver a generar el hash de una contraseña con el nuevo costo la próxima vez que su dueño inicie sesión.

Elige el costo más alto que tu servidor pueda permitirse en cada inicio de sesión, y nunca menos de 10, que es el mínimo que fija para bcrypt la OWASP Password Storage Cheat Sheet. El tiempo que se muestra aquí se mide en WebAssembly dentro de tu navegador, que suele ser más lento que el código nativo de un servidor, así que mídelo en la máquina que vaya a calcular los hashes. Por eso esta herramienta se detiene en el costo 14.

El límite de 72 bytes

bcrypt usa como máximo 72 bytes de la contraseña. El límite es en bytes, no en caracteres: en UTF-8 una letra acentuada como é ocupa dos bytes, la mayoría de los caracteres CJK tres y la mayoría de los emojis cuatro o más. Muchas bibliotecas recortan las entradas más largas sin avisar, lo que significa que dos contraseñas largas que comparten sus primeros 72 bytes se verifican contra el mismo hash. La implementación de Go que se usa aquí se niega a generar el hash de entradas más largas, y esta herramienta te avisa cuando ocurre.

Si tus usuarios pueden elegir contraseñas más largas, lo más sencillo es rechazarlas al registrarse con un mensaje claro. Una solución alternativa habitual calcula primero el SHA-256 de la contraseña y pasa a bcrypt el texto Base64 o hex de ese resumen. Nunca debe pasar los bytes en bruto del resumen, porque algunas implementaciones dejan de leer en un byte cero, y la cheat sheet de OWASP desaconseja este tipo de prehash porque abre la puerta a un ataque llamado password shucking. Para un sistema nuevo, OWASP recomienda Argon2id antes que bcrypt, y Argon2id no tiene el límite de 72 bytes.

Cómo leer un hash, y cómo funciona esta herramienta

Un hash bcrypt tiene 60 caracteres: un prefijo de versión como $2b$, un costo de dos dígitos y $, 22 caracteres de sal y 31 de resumen, ambos en el alfabeto Base64 propio de bcrypt (./A-Za-z0-9). Todo lo necesario para comprobar una contraseña está en esa única cadena, así que no hay que guardar la sal en una columna aparte.

El hash y la comprobación los calcula el paquete golang.org/x/crypto/bcrypt de Go compilado a WebAssembly y ejecutado en un hilo en segundo plano de tu navegador. Las contraseñas y los hashes no se envían a ninguna parte ni se guardan. La página está pensada para datos de prueba, fixtures y para comprobar un hash que ya tienes: el hash de las contraseñas de usuarios reales debe generarlo tu aplicación, en tu servidor.