bcrypt: costo vs tiempo🌎 Actualizado abril de 2026
bcrypt es una función de hashing de contraseñas diseñada por Niels Provos y David Mazières en 1999, basada en el cifrado Blowfish. Su característica más importante es el factor de costo (cost factor), un parámetro que controla cuántas iteraciones de expansión de clave se ejecutan: el tiempo de cómputo se duplica con cada incremento de 1 en el costo. La fórmula base es iteraciones = 2^cost, lo que significa que cost=10 implica 1.024 iteraciones y cost=14 implica 16.384 iteraciones. Se usa para proteger contraseñas almacenadas en bases de datos, impidiendo ataques de fuerza bruta mediante el encarecimiento deliberado del cómputo. Esta calculadora te muestra cuántos hashes por segundo puede generar tu servidor y cuánto tiempo tardaría un atacante en crackear una contraseña con hardware moderno.
Cuándo usar esta calculadora
- Configurar el cost factor de bcrypt en un sistema de login para que cada autenticación tome ~100 ms, frenando ataques de diccionario sin afectar la experiencia del usuario.
- Estimar cuánto tiempo tardaría una GPU RTX 4090 (circa 184.000 hashes/seg en MD5 vs ~2.700 hashes/seg en bcrypt cost=10) en crackear una contraseña robada de una base de datos.
- Comparar el costo computacional de bcrypt cost=10 vs cost=14 para decidir el balance entre seguridad y carga de CPU en un servidor de autenticación con 500 usuarios concurrentes.
- Auditar la configuración de seguridad de una aplicación web existente y determinar si el cost factor usado en producción sigue siendo adecuado frente a hardware más moderno disponible en 2025–2026.
Ejemplo de cálculo
- cost=12
- ~100 ms
Cómo funciona
4 min de lecturaCómo se calcula
El tiempo de cómputo de un hash bcrypt escala de forma exponencial con el cost factor. La relación fundamental es:
iteraciones = 2^cost
tiempo_hash ≈ tiempo_base × 2^(cost - cost_base)
hashes_por_segundo = 1 / tiempo_hash_en_segundosEjemplo concreto: Si en tu servidor cost=10 tarda 65 ms (≈ 15 hashes/seg), entonces:
El tiempo de cracking de un atacante con hardware dedicado se estima así:
tiempo_cracking = tamaño_espacio_contraseña / hashes_por_segundo_atacante
tamaño_espacio = caracteres_posibles ^ longitud
Ejemplo 8 chars alfanuméricos: 62^8 ≈ 218.340.105.584.896 combinaciones---
Tabla de referencia
| Cost | Iteraciones | Tiempo aprox. (CPU moderna) | Hashes/seg CPU | Hashes/seg GPU RTX 4090 | Tiempo cracking 8 chars (GPU) |
|---|---|---|---|---|---|
| 8 | 256 | ~6 ms | ~167 | ~12.800 | ~198 días |
| 10 | 1.024 | ~25 ms | ~40 | ~3.200 | ~2,2 años |
| 11 | 2.048 | ~50 ms | ~20 | ~1.600 | ~4,3 años |
| 12 | 4.096 | ~100 ms | ~10 | ~800 | ~8,7 años |
| 13 | 8.192 | ~200 ms | ~5 | ~400 | ~17,4 años |
| 14 | 16.384 | ~400 ms | ~2,5 | ~200 | ~34,8 años |
| 16 | 65.536 | ~1.600 ms | ~0,6 | ~50 | ~138 años |
> Nota: Los valores de GPU corresponden a ataques offline con hashcat sobre hardware 2024–2025. El espacio estimado es contraseña de 8 caracteres alfanuméricos (62 chars posibles).
---
Casos típicos
Caso 1 — App web con login de usuarios (cost=12)
Un servidor con CPU de 4 núcleos (tipo AWS t3.medium) genera aproximadamente 10 hashes/seg por núcleo con cost=12. Con 500 usuarios que inician sesión en el pico del día (distribuidos en 60 segundos), necesitás procesar ~8 hashes/seg, lo cual cabe cómodamente. Un atacante con RTX 4090 que roba la base de datos puede intentar ~800 hashes/seg, tardando estadísticamente ~8,7 años en crackear una contraseña de 8 caracteres alfanuméricos. Cost=12 es el mínimo recomendado por OWASP para 2025.
Caso 2 — Sistema de salud o bancario (cost=14)
Para datos sensibles, cost=14 sube el tiempo por hash a ~400 ms. Esto reduce los intentos de un atacante GPU a ~200 hashes/seg, extendiendo el cracking a ~35 años para una contraseña de 8 caracteres. El impacto en UX es aceptable si los logins no son masivamente concurrentes: un servidor puede autenticar ~150 usuarios/minuto por núcleo.
Caso 3 — Contraseña débil (cost=12, 6 chars numéricos)
Con cost=12 y una contraseña de solo 6 dígitos (10^6 = 1.000.000 combinaciones), un atacante GPU tarda:
1.000.000 / 800 = 1.250 segundos ≈ 21 minutos. Esto demuestra que el cost factor no salva contraseñas cortas: la longitud y complejidad de la contraseña sigue siendo crítica.---
Errores comunes
1. Usar cost=4 o cost=6 en producción → Valores usados en tests/benchmarks, pero en producción permiten millones de intentos por hora incluso en CPU. Nunca usar cost < 10 en sistemas reales.
2. Confundir "rondas" con "iteraciones" → En bcrypt, el parámetro que se configura se llama "work factor" o "cost", no "rondas" directamente. Las rondas internas son siempre 64; el cost controla la expansión de clave (2^cost veces).
3. Comparar bcrypt con MD5 o SHA-256 en contexto de contraseñas → MD5 y SHA-256 son hashes de propósito general, diseñados para ser rápidos. Una GPU puede calcular >10.000 millones de hashes MD5/seg, haciendo inútil cualquier contraseña corta. bcrypt es deliberadamente lento.
4. No actualizar el cost factor con el paso del tiempo → La recomendación es que el hash de una contraseña tarde al menos 100 ms. A medida que el hardware se vuelve más potente, el cost debe incrementarse. Un sistema que usaba cost=10 en 2015 debería haber migrado a cost=12 o más para 2025.
5. Hashear la contraseña antes de pasarla a bcrypt → bcrypt tiene un límite interno de 72 bytes. Si pre-hasheás con SHA-256 (salida binaria de 32 bytes) para sortear el límite, recordá usar la representación hexadecimal o base64 para no introducir bytes nulos que truncan el input.
---
Calculadoras relacionadas
Preguntas frecuentes
¿Qué cost factor de bcrypt se recomienda usar en 2025–2026?
OWASP recomienda que el hash de una contraseña tarde al menos 100 ms en el servidor de producción. Esto equivale aproximadamente a cost=12 en hardware de CPU moderno (2024–2025). Para sistemas con datos sensibles (salud, finanzas), se recomienda cost=13 o cost=14. El valor mínimo aceptable para cualquier sistema en producción es cost=10.
¿Por qué bcrypt es más seguro que SHA-256 para contraseñas?
SHA-256 es un hash rápido: una GPU RTX 4090 puede calcular más de 20.000 millones de hashes SHA-256 por segundo, lo que permite crackear contraseñas de 8 caracteres en segundos. bcrypt con cost=12 reduce esa velocidad a ~800 hashes/seg en la misma GPU, haciendo el ataque ~25 millones de veces más lento. bcrypt fue diseñado específicamente para ser costoso computacionalmente y resistir mejoras de hardware.
¿Qué pasa si subo el cost factor en mi aplicación existente?
bcrypt es compatible hacia adelante: podés cambiar el cost factor en cualquier momento. Las contraseñas ya hasheadas con el cost anterior siguen siendo válidas (el cost está embebido en el hash). La migración ocurre naturalmente: la próxima vez que cada usuario inicia sesión y su contraseña es verificada, podés re-hashear con el nuevo cost y reemplazar el hash almacenado.
¿bcrypt tiene algún límite técnico en la longitud de la contraseña?
Sí. La implementación estándar de bcrypt tiene un límite de 72 bytes. Contraseñas más largas son truncadas silenciosamente. Esto significa que dos contraseñas que comparten los primeros 72 bytes producen el mismo hash. Para contraseñas más largas, se recomienda pre-hashear con SHA-256 (usando la salida en hexadecimal o base64) antes de pasarla a bcrypt, o bien usar Argon2id que no tiene este límite.
¿Qué diferencia hay entre bcrypt, scrypt y Argon2?
Los tres son algoritmos de hashing de contraseñas con costo ajustable. bcrypt (1999) solo ajusta CPU. scrypt (2009) agrega costo de memoria, dificultando el uso de GPUs/ASICs. Argon2id (ganador de la Password Hashing Competition 2015) es el más moderno: ajusta CPU, memoria y paralelismo simultáneamente. OWASP recomienda Argon2id como primera opción en sistemas nuevos, bcrypt como alternativa probada.
¿Cómo afecta el cost factor al rendimiento de mi servidor bajo carga?
Con cost=12 (~100 ms/hash), un núcleo de CPU puede procesar ~10 logins/seg. En un servidor de 4 núcleos, eso es ~40 logins/seg o ~2.400 logins/minuto. Si tu sistema tiene picos mayores, podés usar una cola de autenticación asíncrona o escalar horizontalmente. Aumentar de cost=12 a cost=14 cuadruplica el tiempo de cómputo, reduciendo la capacidad a ~600 logins/minuto por servidor de 4 núcleos.
¿El salt en bcrypt lo tengo que generar yo manualmente?
No. bcrypt genera automáticamente un salt aleatorio de 128 bits (16 bytes) cada vez que se crea un hash. Este salt queda embebido en el string resultante (que tiene formato $2b$cost$salt+hash). Esto garantiza que dos contraseñas idénticas produzcan hashes distintos, eliminando el riesgo de ataques con tablas rainbow. Nunca reutilizés salts ni los generés manualmente salvo que uses una librería de muy bajo nivel.
¿Cuánto tiempo tardaría crackear mi contraseña si alguien roba la base de datos?
Depende de la longitud y complejidad de la contraseña y del cost factor. Con cost=12 y una GPU RTX 4090 (~800 hashes/seg): una contraseña de 6 dígitos se crackea en ~21 minutos; una de 8 caracteres alfanuméricos en ~8,7 años; una de 10 caracteres con símbolos (espacio de ~95 chars) en más de 1 millón de años. La longitud de la contraseña es el factor más determinante.
Fuentes y referencias
Metodología y confianza
Contenido revisado por el equipo editorial de Hacé Cuentas, con apego a nuestra política editorial y metodología de cálculo.
Última revisión: 18 de abril de 2026. Los parámetros fiscales, legales y datos se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos. Leé nuestra política de privacidad.
Resultados orientativos. Para decisiones financieras, médicas o legales críticas, consultá con un profesional.