Cuando los desarrolladores comparan MD5 vs SHA-256 vs bcrypt para almacenar contraseñas, el consejo habitual es "MD5 está roto, usa SHA-256". Ese consejo es incorrecto y es el error de seguridad más común en este ámbito. MD5 está roto, sí. Pero SHA-256 sin procesar también es una mala elección para contraseñas, por una razón completamente diferente: es demasiado rápido. La respuesta correcta es un algoritmo deliberadamente lento diseñado para contraseñas, lo que significa bcrypt o Argon2.
Esta guía aclara la distinción que el resto de los resultados de búsqueda omiten. Cubriremos por qué los hashes rápidos pierden frente a las GPU, qué hacen realmente el salting y los factores de trabajo, y exactamente qué algoritmo elegir en 2026. Puedes probar cada tipo de hash tú mismo en el navegador mientras avanzamos.
MD5 vs SHA-256 vs bcrypt de un vistazo#
El error principal es tratar todo el hashing como una sola tarea. En realidad son dos tareas diferentes con requisitos opuestos. La integridad de archivos necesita un hash rápido. El almacenamiento de contraseñas necesita uno lento. Confundirlos es la razón por la que las bases de datos filtradas se descifran en horas.
| Algoritmo | Tipo | Velocidad | Sal incorporada | ¿Seguro para contraseñas? | Bueno para |
|---|---|---|---|---|---|
| MD5 | Hash rápido | Extremadamente rápido | No | No (roto) | Nada relacionado con seguridad |
| SHA-1 | Hash rápido | Muy rápido | No | No (roto) | Solo compatibilidad heredada |
| SHA-256 | Hash rápido | Muy rápido | No | No (demasiado rápido) | Sumas de verificación, integridad, firmas |
| bcrypt | Hash lento (KDF) | Ajustable, lento | Sí | Sí | Almacenamiento de contraseñas |
| Argon2id | Hash lento (KDF) | Ajustable, lento | Sí | Sí (mejor actual) | Almacenamiento de contraseñas |
| PBKDF2 | Hash lento (KDF) | Ajustable, lento | Sí (tú lo agregas) | Sí (aceptable) | Entornos con restricciones FIPS |
Conclusión clave: SHA-256 es excelente para la tarea para la que fue diseñado (demostrar que un archivo no fue alterado) e inseguro para una tarea para la que nunca fue diseñado (resistir hardware de descifrado de contraseñas). "Hash seguro" no significa "seguro para contraseñas".
La palabra "seguro" causa la mayor parte de la confusión. SHA-256 es miembro de la familia SHA-2 y es criptográficamente seguro en el sentido de que no se pueden encontrar colisiones ni revertirlo matemáticamente. Esa propiedad es lo que necesita la integridad de archivos. El almacenamiento de contraseñas necesita algo completamente diferente: resistencia a la fuerza bruta a gran escala.
Por qué MD5 está roto (y SHA-1 también)#
MD5 falla en dos frentes. Primero, está roto en cuanto a colisiones: los investigadores pueden producir deliberadamente dos entradas diferentes con el mismo resumen MD5, lo que destruye su valor para firmas y certificados. SHA-1 sufrió la misma suerte con el trabajo práctico de colisiones publicado en 2017.
Segundo, y más relevante para contraseñas, MD5 es extremadamente rápido. Una GPU moderna puede calcular miles de millones de hashes MD5 por segundo. Esa velocidad es una ventaja para un checksum y una catástrofe para un hash de contraseña.
Esto es lo que esa velocidad significa en la práctica. Si un sitio almacena contraseñas como MD5 simple y la base de datos se filtra, un atacante con una sola tarjeta gráfica de consumo puede probar un enorme diccionario de contraseñas comunes contra cada cuenta casi al instante. Agregue una tabla rainbow precomputada (una búsqueda gigante de hash a texto plano) y los hashes MD5 sin sal de contraseñas comunes se revierten en milisegundos.
- MD5: roto por colisiones, demasiado rápido, sin sal. Nunca lo use para seguridad.
- SHA-1: roto por colisiones desde 2017, demasiado rápido. Obsoleto en todas partes.
- La lección: "roto" aquí se refiere en parte a colisiones y en parte a velocidad bruta.
Todavía puede usar MD5 o SHA-256 de forma segura para verificaciones de corrupción no adversariales (¿se descargó este archivo intacto?). Eso es integridad, no autenticidad, y no almacenamiento de contraseñas. Para cualquier cosa que un atacante quiera falsificar o descifrar, MD5 está descartado.
La trampa de SHA-256: segura pero demasiado rápida para contraseñas#
Esta es la parte que la mayoría de las comparaciones fallan. SHA-256 no está roto por colisiones. Es un hash criptográfico genuinamente fuerte. Entonces, ¿por qué es la herramienta equivocada para contraseñas?
Porque es rápido a propósito. SHA-256 fue diseñado para que los sistemas puedan hashear grandes cantidades de datos rápidamente para verificar integridad. Un equipo de GPU de alta gama puede calcular del orden de miles de millones de hashes SHA-256 por segundo. Cuando el algoritmo es rápido, la máquina de fuerza bruta del atacante también es rápida.
El descifrado de contraseñas es un juego de adivinanzas offline. Una vez que un atacante tiene tu base de datos de hashes, nada limita su velocidad. No están iniciando sesión en tu sitio un intento a la vez. Están ejecutando tus hashes contra listas de palabras y reglas de mutación en hardware dedicado. Cuanto más rápida sea tu función hash, más intentos por segundo obtendrán, y más barata será cada contraseña descifrada.
Salar ayuda, pero no soluciona la velocidad#
Una réplica común es "solo sala tu SHA-256". Una sal es un valor aleatorio único almacenado junto a cada hash y mezclado en la entrada antes de hashear. Salar es esencial, y hace dos cosas reales:
- Derrota las tablas rainbow, porque una tabla precomputada es inútil contra sales aleatorias por usuario.
- Asegura que dos usuarios con la misma contraseña obtengan hashes diferentes, por lo que descifrar uno no descifra el otro.
Pero salar no hace nada con la velocidad. Un atacante aún descifra cada hash SHA-256 salado uno a la vez a miles de millones de intentos por segundo. La sal elimina el atajo de precomputación masiva; no hace que la función subyacente sea lenta. Por eso "SHA-256 salado" es mejor que SHA-256 puro y aún no es suficientemente bueno para contraseñas.
El modelo mental: la sal protege contra la precomputación. Un algoritmo lento protege contra el rendimiento bruto de fuerza bruta. Necesitas ambos, y SHA-256 solo te da uno de ellos.
Lo que bcrypt hace de manera diferente: lento a propósito#
bcrypt fue diseñado en 1999 específicamente para el almacenamiento de contraseñas, y su idea central es lo opuesto a MD5 y SHA-256: es deliberadamente y ajustablemente lento. bcrypt agrupa tres cosas que necesita un hash de contraseña.
- Una sal incorporada. bcrypt genera y almacena una sal por hash automáticamente, para que no olvides agregar una.
- Un factor de trabajo (el "costo"). Es un número que configuras y controla cuántas iteraciones internas ejecuta bcrypt. Cada incremento de uno aproximadamente duplica el tiempo para calcular un hash.
- Un diseño adaptativo. A medida que el hardware se vuelve más rápido, aumentas el factor de trabajo para mantener el hash lento, sin cambiar de algoritmo.
Una cadena de hash bcrypt lleva sus propios parámetros. Un hash típico se ve como $2b$12$R9h/cIPz0gi..., donde $2b$ es la versión de bcrypt, 12 es el factor de trabajo (costo), y el resto es la sal y el resumen combinados. Ese formato autodescriptivo significa que la verificación solo necesita el hash almacenado, no una columna de sal separada.
El objetivo del factor de trabajo es hacer que cada intento individual sea costoso. Si un hash bcrypt tarda un cuarto de segundo en calcularse, un atacante que podría hacer miles de millones de intentos SHA-256 por segundo ahora se reduce a unos pocos intentos bcrypt por segundo por núcleo. La misma lista de palabras que descifra SHA-256 en minutos podría tardar años contra bcrypt bien configurado.
Elegir un factor de trabajo de bcrypt#
El factor de trabajo es un equilibrio entre la seguridad y la latencia de inicio de sesión de tu propio servidor. Ajústalo para que un solo hash tome una cantidad notable pero tolerable de tiempo en tu hardware, normalmente ajustado para estar en el rango de 0.1 a 0.5 segundos por hash.
- Un costo más alto es más seguro, pero ralentiza cada inicio de sesión y cada registro.
- Realiza pruebas comparativas en tu hardware de producción real, no en tu portátil. Los servidores más rápidos pueden permitirse un costo más alto.
- Reevalúa anualmente. El hardware mejora, por lo que un costo que era doloroso para los atacantes en 2020 ahora es más barato.
bcrypt también tiene una peculiaridad que vale la pena conocer: trunca la entrada a 72 bytes. Si soportas frases de contraseña muy largas o contraseñas pre-hasheadas (un patrón que algunos equipos usan), prueba ese comportamiento para no ignorar caracteres más allá del límite en silencio.
Dónde encaja Argon2 (y PBKDF2)#
bcrypt es excelente y sigue siendo una opción perfectamente defendible en 2026. Pero la recomendación principal actual de guías de seguridad como la hoja de trucos de almacenamiento de contraseñas de OWASP es Argon2id, el ganador del Concurso de Hash de Contraseñas de 2015.
Argon2id mejora bcrypt al ser resistente a la memoria. El factor de trabajo de bcrypt consume tiempo de CPU, pero usa poca memoria, lo que permite a los atacantes empaquetar muchos núcleos de descifrado de bcrypt en hardware barato. Argon2id permite ajustar tres parámetros: costo de tiempo (iteraciones), costo de memoria (cuánta RAM necesita cada hash) y paralelismo. Forzar que cada intento consuma memoria significativa reduce la ventaja de GPU y ASIC que hace que el descifrado sea barato.
| Algoritmo | Resiste descifrado con GPU | Resistente a memoria | Cuándo elegirlo |
|---|---|---|---|
| Argon2id | Fuerte | Sí | Sistemas nuevos; la recomendación predeterminada actual |
| bcrypt | Fuerte | No | Maduro, probado en batalla; adecuado para sistemas existentes |
| scrypt | Fuerte | Sí | Alternativa válida resistente a memoria si Argon2 no está disponible |
| PBKDF2 | Moderado | No | Requisitos de cumplimiento FIPS-140; usar recuentos de iteraciones altos |
PBKDF2 merece una mención porque aparece en entornos regulados. Es más antiguo y no es resistente a la memoria, por lo que resiste menos a las GPU que bcrypt o Argon2. Pero está aprobado por FIPS, lo que importa para el gobierno y algunos trabajos empresariales. Si debe usar PBKDF2, eleve el recuento de iteraciones (cientos de miles a millones, ajustado a su presupuesto de latencia).
La versión resumida del árbol de decisión:
- Proyecto nuevo sin restricciones: use Argon2id.
- Sistema existente que ya usa bcrypt y funciona: bcrypt está bien, manténgalo, aumente el costo con el tiempo.
- Entorno FIPS o de cumplimiento estricto: PBKDF2 con un recuento de iteraciones muy alto.
- Nunca: MD5, SHA-1, SHA-256 simple, SHA-512 simple o cualquier hash rápido sin sal.
Prueba cada hash tú mismo#
Leer sobre hashes es una cosa. Verlos es otra, y hace que la diferencia de velocidad sea clara. Puedes generar resúmenes MD5, SHA-1, SHA-256 y SHA-512 de la misma entrada en el navegador para ver cómo cada algoritmo transforma el texto.
Pega una cadena de ejemplo como correct horse battery staple en el generador de hash gratuito y observa cómo produce cada resumen al instante. Ese resultado instantáneo es exactamente el problema de los hashes rápidos para contraseñas: si tu navegador calcula un resumen SHA-256 sin demora perceptible, imagina una granja de GPU haciendo miles de millones por segundo contra una base de datos filtrada.
Algunas cosas que probar mientras experimentas:
- Hashea la misma palabra dos veces. Nota que MD5 y SHA-256 dan la misma salida cada vez, por lo que necesitan una sal externa y por lo que las tablas rainbow funcionan contra ellos.
- Cambia un carácter. Todo el resumen cambia por completo (el efecto avalancha), lo cual es bueno para verificaciones de integridad.
- Compara las longitudes de los resúmenes. SHA-256 es más largo que MD5, pero la longitud por sí sola no lo hace seguro para contraseñas. La velocidad es el verdadero problema.
Nota: una herramienta de hash rápido del lado del navegador es la forma correcta de aprender qué producen estos algoritmos, pero no es donde debes generar hashes de contraseñas en producción. bcrypt y Argon2 pertenecen al lado del servidor en tu biblioteca de autenticación, nunca en JavaScript del cliente.
Mientras piensas en la seguridad de las credenciales, vale la pena comprobar qué tan resistentes son tus propias contraseñas. Una contraseña fuerte y un hash lento trabajan juntos: las contraseñas débiles caen ante cualquier hash, y un hash excelente no puede salvar completamente una contraseña que está en todas las listas de palabras. Prueba algunas en el verificador de fortaleza de contraseñas para ver cómo influyen la adivinabilidad y la entropía, y genera unas realmente aleatorias con el generador de contraseñas seguras para que las matemáticas de descifrado estén de tu lado.
Errores comunes que debes evitar#
La teoría es simple, pero los mismos errores de implementación aparecen una y otra vez en las filtraciones. Presta atención a estos.
- Usar SHA-256 porque es "más seguro que MD5". Lo es contra colisiones. Pero sigue siendo demasiado rápido para contraseñas. Esta es la trampa que todo este artículo busca señalar.
- Crear tu propio esquema como
sha256(sha256(password) + salt). Apilar hashes rápidos no crea un hash lento. Usa un KDF de contraseñas real. - Almacenar el salt incorrectamente o reutilizar un salt global. Los salts deben ser únicos y aleatorios por usuario. bcrypt y Argon2 manejan esto por ti, una razón más para usarlos.
- Configurar un factor de trabajo una vez y nunca aumentarlo. Un costo que dificultaba a los atacantes hace años ahora es barato. Revísalo periódicamente.
- Hashear contraseñas en JavaScript del lado del cliente. El hash debe ocurrir en el servidor. Un hash del lado del cliente se convierte en la nueva contraseña que un atacante puede reutilizar.
Si también manejas tokens en lugar de solo contraseñas almacenadas, la misma lógica de "usar la primitiva correcta" aplica para firmas y verificación. Nuestra guía sobre decodificar vs verificar un JWT cubre un error relacionado: confiar en un token que solo decodificaste pero nunca verificaste criptográficamente.
El veredicto sobre MD5 vs SHA-256 vs bcrypt#
Para el almacenamiento de contraseñas, la clasificación no es reñida. MD5 está roto y es demasiado rápido. SHA-256 es criptográficamente fuerte pero sigue siendo demasiado rápido, incluso con sal, por lo que pierde frente a la fuerza bruta con GPU en cuanto tu base de datos se filtra. bcrypt y Argon2id son lentos a propósito, añaden sal automáticamente y te permiten aumentar el costo a medida que el hardware mejora, que es exactamente lo que exige el almacenamiento de contraseñas.
Así que cuando alguien te plantee la pregunta de MD5 vs SHA-256 vs bcrypt para contraseñas, la respuesta es bcrypt o Argon2id, siempre. Reserva SHA-256 para lo que realmente es excelente, como la integridad de archivos y sumas de verificación, y nunca dejes que una etiqueta de "hash seguro" te engañe para usar un algoritmo rápido donde corresponde uno lento. Prueba cada resumen en el generador de hash gratuito para hacer tangible la diferencia de velocidad, y luego mantén los algoritmos lentos y específicos para contraseñas en tu capa de autenticación, donde deben estar.
Preguntas Frecuentes#
¿Es SHA-256 seguro para contraseñas? No, aunque SHA-256 en sí mismo es un hash criptográfico fuerte y no roto. El problema es la velocidad: SHA-256 está diseñado para ser rápido, por lo que un atacante con una base de datos filtrada puede probar miles de millones de conjeturas por segundo en una GPU. El uso de sal ayuda contra las tablas rainbow pero no ralentiza el algoritmo. Para contraseñas, use una función deliberadamente lenta como bcrypt o Argon2id.
¿Por qué bcrypt es mejor que SHA-256 para contraseñas? bcrypt es intencionalmente lento y ajustable, mientras que SHA-256 es intencionalmente rápido. bcrypt incluye una sal incorporada y un factor de trabajo ajustable, por lo que cada intento de contraseña le cuesta al atacante tiempo y dinero reales. A medida que el hardware mejora, se aumenta el factor de trabajo para mantener el coste de descifrado alto. SHA-256 le da a los atacantes conjeturas baratas y de alto rendimiento, que es lo opuesto a lo que necesita el almacenamiento de contraseñas.
¿Debería usar bcrypt o Argon2 en 2026? Ambos son sólidos. Argon2id es la recomendación principal actual porque es resistente a la memoria, lo que reduce la ventaja de GPU y ASIC que hace que el descifrado sea barato. bcrypt sigue siendo una opción perfectamente defendible y probada, especialmente si su sistema ya lo usa. Para un proyecto nuevo sin restricciones de cumplimiento, opte por Argon2id; si ya usa bcrypt y ajusta el coste, no hay una razón urgente para migrar.
¿Es suficiente el uso de sal para hacer que SHA-256 sea seguro para contraseñas? No. El uso de sal es necesario y siempre debe hacerse, pero solo resuelve un problema: evita las tablas rainbow precomputadas y asegura que contraseñas idénticas produzcan hashes diferentes. El uso de sal no hace nada respecto a la velocidad del algoritmo, por lo que un atacante aún descifra cada hash SHA-256 con sal a miles de millones de conjeturas por segundo. Se necesita tanto una sal única como un algoritmo lento, que es exactamente lo que proporcionan bcrypt y Argon2.
¿Es seguro usar MD5 para algo? Solo para comprobaciones de corrupción no relacionadas con la seguridad, como confirmar que un archivo se descargó sin errores. MD5 tiene colisiones, por lo que nunca debe usarse para firmas digitales, certificados, contraseñas o cualquier cosa que un atacante pueda querer falsificar o descifrar. Incluso para la integridad de archivos contra un adversario real, prefiera SHA-256. Puede ver cómo se compara MD5 con otros resúmenes usando un generador de hash gratuito.
¿Qué es un factor de trabajo en bcrypt? El factor de trabajo (también llamado coste) es un número que controla cuántas iteraciones internas realiza bcrypt. Cada incremento de uno aproximadamente duplica el tiempo para calcular un solo hash. Se establece para que un hash tome una fracción de segundo pequeña pero notable en su hardware de producción, lo que mantiene los inicios de sesión rápidos para usted mientras hace que el descifrado masivo sea lento para los atacantes. Auméntelo con el tiempo a medida que el hardware se vuelve más rápido.
