Calculadora bcrypt: cost factor, tiempo por hash y seguridad
Ingresá el cost factor de bcrypt y calculá cuántos ms tarda cada hash, cuántos hashes/seg genera tu servidor y si cumple el mínimo OWASP 2026. Con tabla de referencia cost 8–16.
Ver cálculo paso a paso
Creado en 1999 por Niels Provos y David Mazières para OpenBSD, bcrypt usa el cifrado Blowfish con un mecanismo de expansión de clave adaptativo. El parámetro central es el factor de costo (cost factor): un número entero que determina cuántas iteraciones se ejecutan según la fórmula iteraciones = 2^cost. Cost 10 = 1.024 iteraciones. Cost 12 = 4.096 iteraciones. Cost 14 = 16.384 iteraciones. Cada vez que subís 1, el tiempo de cómputo se duplica exactamente.
Eso tiene una consecuencia brutal para los atacantes: una GPU RTX 4090 puede calcular más de 184.000 millones de hashes MD5 por segundo, pero con bcrypt cost=12 baja a apenas ~800 hashes por segundo. Ese freno artificial es el punto. No es un bug ni una ineficiencia: es el diseño.
El problema práctico para los desarrolladores es encontrar el balance: demasiado bajo y la seguridad es insuficiente frente al hardware de 2025–2026; demasiado alto y el servidor no aguanta la carga de autenticaciones concurrentes.
Esta calculadora te muestra exactamente eso: dado un cost factor, cuántos hashes por segundo puede generar tu servidor, cuánto tarda un atacante con hardware moderno en crackear una contraseña típica, y si tu configuración actual cumple con las recomendaciones vigentes de OWASP. Sin necesidad de correr benchmarks en producción.
Cuándo usar esta calculadora
- Un desarrollador freelance configura el login de un e-commerce y elige cost=12: cada autenticación tarda ~100 ms, lo que permite hasta 10 logins/seg por núcleo de CPU sin afectar la experiencia del usuario.
- Una fintech que almacena datos de tarjetas de crédito evalúa subir de cost=12 a cost=14: la calculadora muestra que el tiempo de cómputo se cuadruplica a ~400 ms/hash, reduciendo la capacidad de un servidor de 4 núcleos de 2.400 a 600 logins/minuto — y decide escalar horizontalmente antes de subir el cost.
- Un sysadmin descubre que la app heredada usa cost=8 (configuración de 2012): la calculadora confirma que una RTX 4090 puede intentar ~12.800 hashes/seg, reduciendo el tiempo de cracking de una contraseña de 8 caracteres alfanuméricos de años a meses — justificando una migración urgente.
- Un equipo de seguridad de una empresa de salud compara bcrypt cost=13 vs Argon2id para una nueva plataforma de historia clínica digital: usan la calculadora para estimar la carga de CPU con 200 autenticaciones simultáneas y determinar si el hardware actual los soporta.
- Un estudiante de sistemas aprende la diferencia entre SHA-256 y bcrypt: con la calculadora visualiza que cost=10 genera ~40 hashes/seg vs los 20.000 millones de SHA-256/seg de la misma GPU — un factor de ~500 millones de veces más lento.
- Un CTO debe justificar ante el directorio por qué migrar de MD5 (sistema legado) a bcrypt cost=12 implica un costo de infraestructura mayor pero reduce el riesgo de breach a niveles aceptables según OWASP.
- Un pentester evalúa cuánto tiempo le llevaría a un atacante con una granja de 10 GPUs RTX 4090 crackear las contraseñas robadas de una base de datos con cost=10: la calculadora le permite estimar el impacto real y reportarlo con números concretos en su informe.
- Un desarrollador de una app de gobierno digital en Argentina revisa si su configuración bcrypt cumple con las buenas prácticas de seguridad para sistemas que manejan datos de ciudadanos, alineándose con las recomendaciones de la Oficina Nacional de Tecnologías de Información (ONTI).
Tiempo de cracking por tipo de contraseña con bcrypt cost=12
Ataque offline con 1 GPU RTX 4090 (~800 hashes/seg). Tiempo para recorrer todo el espacio de claves.
| Contraseña | Combinaciones | Tiempo estimado (1 GPU) |
|---|---|---|
| 4 dígitos (PIN) | 10.000 | 12 segundos |
| 6 dígitos | 1.000.000 | 21 minutos |
| 6 alfanuméricos (62 chars) | 5,68×10¹⁰ | ~2 años |
| 8 alfanuméricos | 2,18×10¹⁴ | ~8.650 años |
| 8 con símbolos (95 chars) | 6,63×10¹⁵ | ~263.000 años |
| 10 alfanuméricos | 8,39×10¹⁷ | ~33 millones de años |
| 12 con símbolos | 5,40×10²³ | > 2×10¹³ años |
tiempo = combinaciones ÷ (hashes/seg). Combinaciones = (chars posibles)^longitud. Con cost=10 los tiempos se dividen por ~4; con cost=14 se multiplican por ~4. La longitud de la contraseña pesa mucho más que el cost factor.
Cómo funciona
Cómo se calcula el tiempo de bcrypt
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 25 ms (≈ 40 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: bcrypt cost factor vs seguridad
| Cost | Iteraciones | Tiempo/hash (CPU) | Hashes/seg CPU | Hashes/seg GPU RTX 4090 | Cracking 8 chars alfanum. (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 ✓ OWASP mín. |
| 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 |
> Los valores de GPU corresponden a ataques offline con hashcat sobre hardware 2024–2025. Espacio estimado: contraseña de 8 caracteres alfanuméricos (62 chars posibles, mayúsculas + minúsculas + dígitos).
---
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.
Ejemplo: bcrypt cost=12 (recomendado OWASP)
Preguntas frecuentes
¿Qué es el cost factor de bcrypt y cómo afecta la seguridad?
¿Qué cost factor de bcrypt se recomienda usar en 2025–2026?
¿Por qué bcrypt es mucho más seguro que SHA-256 o MD5 para almacenar contraseñas?
¿Cómo se puede migrar el cost factor en una aplicación que ya está en producción?
¿bcrypt tiene algún límite técnico importante que deba conocer?
¿Cuánto tiempo tardaría crackear una contraseña si alguien roba la base de datos?
¿Cómo afecta el cost factor al rendimiento del servidor bajo carga real?
¿El salt en bcrypt tengo que generarlo yo o lo hace la librería?
¿Qué diferencia hay entre bcrypt, scrypt y Argon2id?
¿Qué es exactamente el string que devuelve bcrypt y cómo se interpreta?
¿Hay alguna normativa argentina que obligue a usar bcrypt u otro algoritmo específico?
¿bcrypt sigue siendo relevante en 2025–2026 o está obsoleto?
Fuentes y referencias
Metodología y confianza
Calculadora de tecnología revisada por el equipo editorial de Hacé Cuentas, contrastada con OWASP Password Storage Cheat Sheet, según nuestra política editorial y metodología.
Última revisión: 12 de junio de 2026. Los parámetros se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos.
Resultados orientativos. Para decisiones críticas, consultá con un profesional.
Rodríguez, M. (2026). Calculadora bcrypt: cost factor, tiempo por hash y seguridad. Hacé Cuentas. https://hacecuentas.com/calculadora-hashes-bcrypt-costo-tiempo-cracking
Contenido bajo licencia CC-BY 4.0 — reutilizable citando la fuente con enlace a Hacé Cuentas.