Generador bcrypt

bcrypt sigue siendo una de las opciones más seguras para almacenar contraseñas. Es deliberadamente lento, deriva su propia sal y se adapta a las mejoras de hardware a través de un parámetro de costo ajustable. Este generador produce un hash bcrypt conforme a los estándares a partir de una contraseña en texto plano, para que puedas sembrar un usuario de prueba, migrar una cuenta entre sistemas o comparar valores con un hash existente almacenado en una columna users.password.

Cómo hashear una contraseña con bcrypt

  1. 1

    Ingresa la contraseña en texto plano

    Hasta 72 bytes — bcrypt trunca silenciosamente más allá de eso.

  2. 2

    Elige un factor de costo

    10 es el valor predeterminado actual; 12 es común para nuevos sistemas; 14 es paranoico. Cada +1 duplica aproximadamente el tiempo de hash.

  3. 3

    Se genera una sal aleatoria

    16 bytes de sal se extraen de un RNG criptográfico y se incrustan en la cadena de hash resultante.

  4. 4

    Copia el hash

    La salida es una cadena autodescriptiva como `$2b$12$...` que incluye versión, costo, sal y digest.

Anatomía de un hash bcrypt

$2b$12$mE2n5YqWjKqT9tXg.OQPoeeHZJ9hdSvOt5wFdRRQwl6yE1vWWY3z6
  |   |  |                      |
  |   |  sal (22 caracteres Base64)  digest (31 caracteres Base64)
  |   costo (2 dígitos, 4-31)
  versión (2a, 2b, 2y — todos bcrypt)

La cadena completa tiene 60 caracteres. Las columnas tipadas como VARCHAR(60) o CHAR(60) son el esquema estándar.

Recomendaciones de factor de costo

Costo Tiempo aproximado por hash (CPU 2024) Caso de uso
10 ~80 ms Predeterminado legado, aún aceptable
12 ~300 ms Línea base recomendada actual
13 ~600 ms Aplicaciones de mayor seguridad
14 ~1.2 s Paranoico; retraso notable en el inicio de sesión

Cada incremento duplica el factor de trabajo. Si la latencia de inicio de sesión por debajo de 500 ms es crítica, mantente en 10-12.

Byte de versión: 2a vs 2b vs 2y

  • $2a$ — Especificación original de 1999. La mayoría de las bibliotecas emiten hashes 2a.
  • $2b$ — Revisión de 2014 que corrige un error de truncamiento en crypt_blowfish. Preferido para nuevos hashes.
  • $2y$ — Etiqueta específica de PHP, funcionalmente equivalente a $2b$.

Los tres se verifican entre sí; solo la etiqueta en la cadena de hash difiere.

Contra qué protege bcrypt

  • Tablas arcoíris — La sal única por hash derrota las búsquedas precomputadas.
  • Cracking GPU/ASIC — La programación de claves de Blowfish está limitada por memoria y es hostil a las GPU. No tan hostil a GPU como Argon2, pero aún lento para la fuerza bruta.
  • Filtraciones de base de datos — El texto plano nunca es recuperable del hash sin fuerza bruta.

Lo que bcrypt NO protege: contraseñas débiles (usa una longitud mínima y verifica contra listas de filtraciones), relleno de credenciales (usa un segundo factor), phishing.

Límite de 72 bytes

bcrypt usa solo los primeros 72 bytes de la contraseña. Las entradas más largas se truncan silenciosamente, que es la misma razón por la que muchas bibliotecas ahora recomiendan pre-hashear la contraseña con SHA-256 antes de alimentarla a bcrypt. Las alternativas modernas (Argon2, scrypt) no tienen tal límite.

Preguntas frecuentes

Sí para el almacenamiento de contraseñas, con costo ≥ 12. OWASP aún lo lista como un algoritmo aceptable. Argon2id es la opción preferida para nuevos sistemas, pero migrar hashes bcrypt heredados es una preocupación de baja prioridad.

Porque la sal se genera aleatoriamente por hash. La verificación toma la sal del hash almacenado, vuelve a hashear la contraseña enviada con ella y compara.

La mayoría de las bibliotecas no exponen esto, y por una buena razón: las sales predecibles derrotan el propósito. Usa la sal generada por la biblioteca; ese es el camino seguro.

Sí — el factor de trabajo es simétrico. Verificar un hash de costo 14 toma 16 veces más que verificar uno de costo 10. Ajusta teniendo en cuenta tu rendimiento de inicio de sesión.

Herramientas relacionadas