bcrypt Generador de Hash
Herramienta gratuita de bcrypt Generador de Hash en línea. Procesamiento 100% local — tus datos nunca salen de tu dispositivo.
El resultado se mostrará aquí...
Entrada → Calcular Hash
Usage Guide
Sobre bcrypt
bcrypt es una función de hash de contraseñas diseñada por Niels Provos y David Mazières en 1999, basada en el cifrado Blowfish. Fue construida específicamente para ser lenta y computacionalmente costosa, haciendo que los ataques de fuerza bruta sean poco prácticos. bcrypt es uno de los algoritmos de hash de contraseñas más ampliamente implementados en el mundo, con soporte nativo en frameworks como Rails, Django, Laravel y Node.js (bcryptjs). Cada hash de bcrypt incorpora un salt aleatorio y el factor de coste, por lo que el hash es completamente autónomo para la verificación.
Pasos de Uso
Esta herramienta admite dos operaciones: hashear una contraseña (Cifrar) y verificar una contraseña contra un hash (Descifrar):
Características del Algoritmo
bcrypt tiene varias propiedades que lo hacen adecuado para el almacenamiento de contraseñas:
Guía del Factor de Coste
Elegir el factor de coste correcto equilibra la seguridad contra el rendimiento del servidor:
FAQ
Q: ¿Cuál es el formato de salida de bcrypt?
A: Un hash bcrypt siempre tiene exactamente 60 caracteres y se ve así: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lewdBdXyXu2zXpOme.
Desglose:$2b$: Identificador de versión de bcrypt.12$: El factor de coste.
Siguientes 22 caracteres: Salt aleatorio de 128 bits codificado en Base64.
Últimos 31 caracteres: Hash derivado de 184 bits codificado en Base64.
Propiedad clave: Todos los parámetros están incorporados en la cadena — no se necesita almacenamiento adicional para verificar una contraseña posteriormente.
Q: ¿Cómo se compara bcrypt con Argon2?
A: bcrypt (1999): difícil computacionalmente, ~4 KB memoria, resistencia moderada a GPU, soporte universal. Argon2 (2015): difícil en memoria (configurable, por defecto 64 MB), resistencia a ASIC/GPU mucho más fuerte, preferido por OWASP y NIST. Cuándo usar bcrypt: Manteniendo un sistema existente o cuando Argon2 aún no está disponible. Cuándo usar Argon2: Todos los proyectos nuevos.
Q: ¿Por qué bcrypt no puede usarse para hashear archivos o datos grandes?
A: bcrypt tiene un límite de entrada de 72 bytes. Los caracteres más allá del byte 72 son ignorados silenciosamente. Para integridad de archivos, use SHA-256 o SHA-512. bcrypt está construido específicamente para contraseñas cortas ingresadas por humanos únicamente.
Q: ¿Es seguro bcrypt si mi base de datos es comprometida?
A: Sí — un hash bcrypt es unidireccional. Con cost=12, un solo núcleo de CPU puede intentar aproximadamente 2–5 hashes por segundo, haciendo los ataques exhaustivos contra contraseñas fuertes efectivamente inviables. Sin embargo, bcrypt no protege contraseñas débiles — siempre aplique una política mínima de fortaleza de contraseñas.
Q: ¿Qué factor de coste debo usar en producción?
A: Recomendación OWASP 2023: cost=12 como línea base. Haga benchmark en su servidor de producción y elija el factor de coste más alto que mantenga el hasheo bajo 500 ms. Nunca baje de cost=10. Revise cada 2–3 años cuando el hardware mejore.
Q: ¿Puede bcrypt usarse para almacenar claves API o tokens?
A: Sí, con advertencias. bcrypt es adecuado para hashear claves API y tokens de menos de 72 bytes y verificados con poca frecuencia. Para verificación de alta frecuencia, use un enfoque rápido de SHA-256 + salt en su lugar.
Use Cases
Recomendado: Almacenamiento de Contraseñas de Usuario
Este es el caso de uso principal de bcrypt. Hashee con bcrypt (cost ≥ 12) y almacene la cadena de 60 caracteres. Durante el login, ejecute la verificación bcrypt. bcrypt está soportado de serie en Rails (has_secure_password), Django, Laravel y Node.js (bcryptjs).
Recomendado: Compatibilidad con Sistemas Legados
Para sistemas que almacenan millones de hashes bcrypt, continúe usando bcrypt y aumente el factor de coste conforme el hardware mejora. Los nuevos usuarios pueden actualizarse transparentemente a Argon2id mientras los hashes bcrypt (identificados por el prefijo $2b$) continúan verificándose correctamente.
- ✅ Mantener bcrypt para hashes existentes — no se necesita migración forzada
- ✅ Introducir gradualmente Argon2id para contraseñas nuevas y actualizadas
- ✅ Usar detección de prefijo de hash ($2b$ vs $argon2id$) para enrutar la verificación
- 💡 Registrar el algoritmo usado por usuario para rastrear el progreso de migración
Aceptable: Hash de Claves API
bcrypt puede hashear claves API antes del almacenamiento en base de datos. Para verificación por solicitud a escala, prefiera un esquema rápido HMAC-SHA256 o un hash SHA-256 de la clave.
- ✅ bcrypt (cost=10–12, bueno para verificación de baja frecuencia)
- ✅ SHA-256 + salt (más rápido, adecuado para claves de alta entropía)
- ✅ HMAC-SHA256 (para firma de tokens por solicitud)
- 💡 Usar prefijo de hash (primeros 8 caracteres) como índice de base de datos para búsqueda rápida
No Recomendado: Cifrado de Archivos o Datos
bcrypt es una función hash unidireccional, no un algoritmo de cifrado. No puede cifrar archivos. Además, el límite de entrada de 72 bytes de bcrypt lo hace inadecuado para hashear contenidos de archivos. Para cifrado de archivos, use un cifrado simétrico (p.ej., AES-256-GCM).
- ❌ No usar bcrypt para cifrado de archivos (no es reversible)
- ❌ No hashear datos de más de 72 bytes con bcrypt
- ✅ Usar AES-256-GCM para cifrado simétrico de archivos
- ✅ Usar Argon2id o scrypt para derivación de claves basada en contraseñas
No Recomendado: Hash General de Datos
bcrypt es demasiado lento para verificaciones de integridad de datos de propósito general. Use SHA-256 o SHA-512 para verificación de integridad.
- ❌ No usar bcrypt para verificaciones de integridad de datos o hash de contenido
- ✅ SHA-256 (hash de integridad de propósito general)
- ✅ BLAKE2b (hash criptográfico de alta velocidad)
- ✅ SHA-3 / SHA-512 (mayor margen de seguridad)
No Recomendado: Autenticación de Alta Frecuencia
bcrypt está diseñado para ser lento (~200–500 ms en cost=12). Ejecutarlo en cada solicitud API llevaría su servidor al límite. Use bcrypt solo una vez en el login — luego emita un JWT firmado para solicitudes posteriores.
- ❌ No ejecutar bcrypt en cada solicitud API
- ✅ JWT + HMAC-SHA256 (auth stateless, rápida por solicitud)
- ✅ Session + Cookie (gestión de sesión tradicional del lado del servidor)
- ✅ OAuth 2.0 / OpenID Connect (identidad federada, basada en tokens)
Resumen de Mejores Prácticas
- Usar bcrypt (cost ≥ 12) para almacenamiento de contraseñas de usuario en sistemas existentes. Para nuevos proyectos, preferir Argon2id.
- Nunca usar bcrypt para hash general de datos, cifrado de archivos o datos mayores de 72 bytes.
- Hacer benchmark en hardware de producción y apuntar a 200–500 ms por hash. Incrementar el factor de coste cada 2–3 años.
- Para escenarios de auth de alta frecuencia, usar bcrypt solo en el login, luego emitir JWT o tokens de sesión.
- Migración gradual de bcrypt a Argon2id: mantener bcrypt para hashes existentes, usar Argon2id para nuevas contraseñas.