Generador de bcrypt - Crea hashes de contraseña online

Para la mayoría de sistemas de producción, un factor de trabajo de 12 es un valor por defecto sólido, que da del orden de 250 a 400 milisegundos por hash en hardware de servidor típico, mientras que un coste 10 hoy resulta a menudo demasiado rápido para resistir a un atacante dedicado con GPUs modernas. La propiedad importante es que debes elegir una cifra que haga que tu propio flujo de inicio de sesión parezca normal, porque el hashing ocurre durante la autenticación y cualquier cosa perceptiblemente lenta es un problema de usabilidad que empuja a la gente hacia atajos de reautenticación. Si tus servidores son inusualmente potentes, mide en coste 12 y sube a 13 o 14 hasta que un solo hash tarde unos cientos de milisegundos. Nunca elijas un coste copiando el número de otro proyecto, ya que esa cifra solo significa algo en relación con el hardware que hace el trabajo, y trata cualquier coste almacenado como algo que hay que volver a medir y aumentar a medida que mejora el hardware.

Porque bcrypt genera una sal aleatoria de 128 bits nueva para cada hash. Esa sal no es un secreto, simplemente se registra en la salida para que el paso de verificación pueda reproducir el cálculo original, pero su aleatoriedad garantiza que contraseñas idénticas produzcan cadenas de hash completamente sin relación entre cuentas distintas. Esto inutiliza toda una clase de ataques de precomputación, incluidas las tablas arcoíris, en las que un atacante hashea por adelantado cada contraseña probable una sola vez y luego busca coincidencias. También evita una fuga más sutil, donde un atacante que obtiene tu tabla de usuarios vería de inmediato qué cuentas comparten contraseña solo comparando las cadenas de hash. La implicación práctica es que no puedes detectar una contraseña reutilizada comparando los hashes bcrypt almacenados, y la comprobación debe hacerse verificando contraseñas candidatas, que es exactamente el motivo por el que detectar contraseñas reutilizadas exige probar deliberadamente una contraseña contra otras cuentas.

Usa bcrypt, y la razón es el factor de coste y no ninguna matemática ingeniosa. Una sola ronda de SHA-256 está diseñada para ser extremadamente rápida, y eso es precisamente lo que no quieres al guardar contraseñas, porque una GPU puede calcular miles de millones por segundo y un atacante que prueba una tabla de hashes filtrada obtiene cantidades enormes de intentos gratis. bcrypt es intencionadamente lento y su coste por hash es ajustable, así que puedes aumentarlo con el tiempo conforme mejora el hardware sin cambiar el formato almacenado. Argon2id es hoy la opción preferida allí donde esté disponible y es en general la recomendación más sólida para sistemas nuevos, mientras que bcrypt sigue siendo perfectamente aceptable y está mucho más ampliamente soportado. Lo que nunca debes hacer es guardar contraseñas como SHA-256 simple, ni como cualquier hash sin sal, sea cual sea el algoritmo que elijas.

No, y esa es precisamente la razón de elegir un hash de contraseña en lugar de un cifrado. bcrypt es una función unidireccional, así que no hay ninguna clave, ningún ajuste ni ninguna herramienta de pago que convierta un hash de vuelta en la contraseña. La única forma práctica de recuperar una contraseña a partir de un hash bcrypt es adivinar contraseñas candidatas, hashear cada una con el mismo coste y la misma sal y comparar, que es justo el ataque que bcrypt está diseñado para hacer lento. Esto explica también una restricción que sorprende a la gente: no puedes usar bcrypt para nada que necesites leer más adelante, como números de tarjeta almacenados, claves de cifrado de clientes o recuperación de contraseña reversible, porque el sistema no podría recuperar el valor original. Eso necesita cifrado real con una clave gestionada, no un hash unidireccional.

Entonces el hash no se podrá verificar nunca y la cuenta será irrecuperable, porque bcrypt necesita las cuatro partes de la cadena para reproducir el cálculo. Un hash bcrypt completo es el prefijo de versión, el coste, la sal y el hash resultante, unidos por signos de dólar, y siempre tiene 60 caracteres de longitud. Bibliotecas como bcryptjs y el paquete bcrypt de Python devuelven toda esa cadena completa desde una sola llamada a generate, así que tu columna de base de datos debe guardar el valor entero y no una porción recortada. Guardar solo el segmento final, o solo la parte posterior a la sal, rompe el inicio de sesión en silencio para todos los usuarios, y depurar la contraseña no servirá de nada. Una comprobación de longitud de 60 caracteres es una prueba de cordura útil en cualquier columna destinada a alojar hashes bcrypt.

bcrypt solo considera los primeros 72 bytes de la contraseña e ignora todo lo que vaya más allá, un artefacto histórico de su plan de claves Blowfish más que un límite de seguridad deliberado. La consecuencia práctica es que dos contraseñas de más de 72 bytes que compartan prefijo se autentican entre sí, así que una frase de paso de 100 caracteres cuyos primeros 72 bytes coincidan con los de otra se trataría como la misma contraseña. Este es un riesgo real con frases de paso largas, que es justo el tipo de contraseña que deberías alentar, y valores largos como oraciones completas pueden superar el límite con facilidad. La mitigación estándar es prehashear la contraseña con SHA-256 y base64 y pasar después ese resultado de longitud fija a bcrypt. Si la biblioteca de tu lenguaje lo gestiona automáticamente, prefiere esa implementación y, en caso contrario, verifica el comportamiento antes de depender de frases de paso muy largas.