MD5 vs SHA-256 para checksums: ¿cuál deberías usar?

Estás en una página de descarga que lista un MD5. O decides qué publicar junto a tu propia versión. En ambos casos surge la misma pregunta: ¿MD5 todavía vale, o necesitas SHA-256? Búscalo y obtendrás una respuesta rotunda: «MD5 está roto, no lo uses nunca». Ese consejo es medio cierto. La mitad que no lo es, es la que induce a error. Si lo sigues a ciegas, pasa una de dos cosas. Malgastas esfuerzo donde MD5 bastaba. O, peor, cambias a SHA-256, te sientes seguro y no ves que lo que de verdad necesitabas nunca fue un hash más fuerte.

La versión honesta es esta. «¿Qué hash?» no es una pregunta sobre qué algoritmo es mejor. Es una pregunta sobre de quién te defiendes. La gente publica o comprueba un hash para perseguir dos objetivos muy distintos, y MD5 sirve perfectamente para uno e inútil para el otro. Hasta que sepas cuál de los dos persigues, ninguna respuesta es correcta.

Una nota de alcance por adelantado: este artículo trata de checksums de archivos, es decir, confirmar que los datos no han cambiado. Guardar contraseñas es otro problema, con otra respuesta. Para eso se usa un hash de contraseñas específico como Argon2id o bcrypt; nunca MD5, y tampoco SHA-256 a secas.

La idea central: dos trabajos, una pregunta

Comparas un hash publicado para lograr uno de dos objetivos. No son el mismo objetivo, y un hash a secas los sirve de forma muy distinta.

1. Detectar corrupción accidental. Una conexión caída truncó el archivo. Un disco inestable volteó un bit. Un servidor espejo sirvió una copia obsoleta. Nadie diseñó esa diferencia: es daño aleatorio, y confías en la fuente que te dio el valor de referencia. Es integridad contra el accidente, y un hash a secas la resuelve por sí solo.
2. Resistir la manipulación deliberada. Alguien quiere que aceptes un archivo malicioso, y trabaja activamente para que su hash coincida con el que esperas. Aquí lo que está en juego es la autenticidad, y un hash a secas es solo parte de la respuesta: una capa necesaria, no toda la defensa. Terminar este trabajo exige una firma (o un HMAC) por encima.

Toda la decisión entre MD5 y SHA-256 gira sobre una pregunta: ¿hay un adversario? Para el objetivo 1 no lo hay, y MD5 cumple. Para el objetivo 2 sí lo hay: MD5 se cae del todo, y SHA-256 pasa a ser el mínimo en la capa del hash. Pero no pierdas de vista la advertencia del objetivo 2: el hash es una capa de esa defensa, nunca toda ella. Acierta con el modelo de amenaza y el algoritmo se decide solo. Fállalo y, o sobredimensionas un problema que no lo pedía, o confías en que un hash haga algo que ningún hash a secas puede hacer.

Qué significa de verdad «MD5 está roto»

La rotura tiene un nombre preciso, y esa precisión es justo el punto. Un hash criptográfico debería tener varias propiedades. MD5 ha perdido exactamente una y ha conservado las demás.

• Resistencia a colisiones. Nadie puede encontrar dos entradas distintas con el mismo hash. Esto es lo que MD5 perdió. Con herramientas ya disponibles se generan colisiones MD5 en un portátil. (Ahora bien, lograr una colisión cuyos dos archivos tengan además un contenido concreto y útil —una colisión de prefijo elegido— es mucho más difícil, y cuánto depende del escenario.) SHA-1 también cayó: el ataque SHAttered de 2017 produjo una colisión real de SHA-1.
• Resistencia a preimagen y a segunda preimagen. Dado un hash, nadie puede construir una entrada que lo produzca (preimagen); y dado un archivo, nadie puede encontrar otro archivo con el mismo hash (segunda preimagen). MD5 conserva las dos, en cualquier sentido práctico. No hay ataque viable que tome un valor MD5 concreto y existente, o un archivo dado, y fabrique algo que coincida.

Esa distinción es justo por qué MD5 todavía sirve para el trabajo 1. La corrupción accidental no es una colisión fabricada. Una descarga truncada o un bit volteado es un archivo que cambió, no dos archivos hechos para coincidir. Y la salida de MD5 cambia de forma fiable cuando cambia la entrada. Verificar una descarga contra un hash que un proveedor de confianza ya calculó es una cuestión de sustitución: se apoya en la resistencia a preimagen y a segunda preimagen, que MD5 no ha perdido. Pero eso no hace a MD5 apto para autenticación, porque su resistencia a colisiones está rota, y esa es la puerta por la que entran los ataques reales.

Entonces, ¿qué le permite hacer de verdad la rotura de colisiones a un atacante? Necesita dos archivos, y controla los dos. Imagina un servicio que firma cualquier archivo que le envíes. El atacante fabrica un archivo de aspecto inocente y un gemelo malvado que comparte el mismo MD5. Envía el inocente, consigue la firma y luego distribuye el gemelo: la firma sigue siendo válida, porque el hash coincide. Esto no es teoría. El malware Flame usó una colisión MD5 para falsificar un certificado de firma de código de Microsoft. Hubo investigadores que fabricaron así certificados de CA fraudulentos. El patrón nunca cambia: el atacante tiene que influir en el archivo «bueno», no solo en el malo. En cuanto tu flujo se lo permite, un hash sin resistencia a colisiones es una puerta abierta. Y cerrarla no cuesta nada, así que no hay razón para dejarla abierta.

Un mapa rápido del terreno

Antes de los detalles, una tabla para mantener los nombres en su sitio:

El resto de esta guía trata, en realidad, de leer bien esa tercera y cuarta columna.

Cuándo MD5 está genuinamente bien

Dejando de lado la moda. MD5 es una elección razonable cuando tienes buenas razones para creer que no hay adversario, y valoras la velocidad o ya tienes valores MD5 a mano.

• Detectar corrupción accidental desde una fuente en la que confías. Copias un archivo por una red inestable, o lo traes de tu propio servidor espejo interno, y quieres confirmar que llegó intacto.
• Deduplicación y claves de caché. Usas un hash para notar «estos dos bloques son idénticos», o para indexar una caché. Nadie dentro de ese sistema intenta forzar una colisión a propósito.
• Comprobar un MD5 que un proveedor de confianza ya te dio. Un proyecto en el que confías, por un canal en el que confías, solo publica un MD5. Comprobarlo sigue atrapando el daño accidental para el que servía. No es inútil. Solo no es protección contra un archivo manipulado.

Una advertencia, dicha claro. Aquí «bien» significa no incorrecto, no recomendado para trabajo nuevo. Y si lo único que necesitas es atrapar corrupción accidental rápido, un checksum no criptográfico como CRC32 o xxHash suele ser mejor herramienta. Está hecho a medida para ese trabajo, es más rápido y no lleva una etiqueta de «seguridad» que alguien malinterprete después.

Cuándo debes usar SHA-256 (o mejor)

Siempre que un atacante pueda influir en la entrada o en el archivo, la regla es simple: en la capa del hash, SHA-256 como mínimo. Te lo cruzas más de lo que crees: es el hash que sostiene la mayoría de los sistemas que ya usas.

• Descargas públicas que podrían manipularse. Cualquier cosa que un usuario baje por la internet abierta, donde un servidor espejo o un intermediario podría sustituir el archivo.
• Cadenas de suministro de software. Una imagen de Docker se fija por su digest SHA-256 (sha256:…). Un paquete de npm registra un hash de Subresource Integrity, casi siempre SHA-512 en base64. Existen para que un artefacto sustituido no pase la comprobación.
• Identificadores derivados de un hash, cercanos a la seguridad. Huellas de certificados TLS, contenido firmado y cualquier identificador que deba resistir una colisión deliberada. (Los tokens secretos son otra cosa: deben venir de un generador de números aleatorios criptográficamente seguro, no de elegir un algoritmo de hash.)
• Direccionamiento por contenido, donde una colisión es un fallo de seguridad y no una simple molestia. Por eso Git está migrando fuera de SHA-1: dos commits distintos con el mismo ID romperían la suposición central del modelo.

Para trabajo nuevo, usa SHA-256 por defecto aunque el uso de hoy parezca no adversario. Los modelos de amenaza cambian con el tiempo. Una herramienta interna se expone. Un flujo «de confianza» gana una entrada no fiable. Y en hardware moderno con extensiones SHA, el coste de SHA-256 frente a MD5 es casi nulo. Partiendo de cero, casi nunca hay razón para recurrir a MD5.

«¿Un hash más largo no es más seguro?» — bits y velocidad

Dos instintos empujan hacia SHA-512, o hacia «el más fuerte». Ambos conviene corregirlos.

Primero: más largo no es automáticamente más seguro. El problema de MD5 y SHA-1 es una rotura estructural de la resistencia a colisiones, no que tengan pocos bits. Más bits de salida sí suben el coste de una búsqueda de colisiones genérica, por fuerza bruta, pero SHA-256 ya tiene ahí un margen enorme; no lo vas a agotar. Lo que la longitud extra no puede hacer es reparar una debilidad estructural, ni añadir autenticidad. SHA-512 no arregla nada que a SHA-256 le falte, porque no le falta.

Segundo: el hash más fuerte no es el más lento, y MD5 ya no es el más rápido. Las CPU modernas llevan instrucciones de hash integradas: SHA-NI en x86, extensiones criptográficas en ARM. Con ellas, SHA-256 corre a gigabytes por segundo, y a menudo iguala o supera a MD5. BLAKE3 va más allá, usando SIMD y varios núcleos, y suele ser el hash criptográfico más rápido que puedes elegir. Si de verdad solo necesitas rendimiento y ninguna seguridad, un CRC32 por hardware los supera a todos. «MD5 es más rápido» era un argumento real hace una década. En el hardware de hoy, rara vez se sostiene.

Así que elige SHA-512 por una razón real: un resumen más largo, o una ventaja de velocidad en un servidor de 64 bits. No por un plus de seguridad que no vas a obtener.

La trampa: un hash más fuerte no es protección contra manipulación

Cambiar MD5 por SHA-256 fomenta en silencio un error, así que hay que decirlo sin rodeos. Subir el algoritmo, por sí solo, no protege contra la manipulación. Son dos ejes distintos, y confundirlos es lo que convierte «usamos SHA-256» en una falsa sensación de seguridad.

• MD5 → SHA-256 aporta resistencia a colisiones. Solo importa cuando un atacante fabrica las entradas.
• Hash a secas → firma aporta autenticidad. Importa siempre que un atacante pueda alterar tanto el archivo como su hash publicado.

Supón que una descarga y su checksum están en la misma página. Un atacante controla esa página. Sustituye el archivo y reescribe el hash para que cuadre. Da igual que ese hash sea MD5 o SHA-512. La comprobación pasa. Te engañan. El arreglo no es un resumen más largo. Para distribución pública es una firma: GPG, o Ed25519/minisign. El proveedor firma con una clave privada y tú verificas con su clave pública ampliamente difundida, así que el atacante no puede falsificar la referencia sin la clave. Un HMAC resuelve el mismo problema, pero solo en un entorno cerrado donde las dos partes ya comparten una clave secreta —un webhook, o dos servicios internos—, de modo que no sirve para una descarga pública. Por eso las distribuciones de Linux entregan un archivo de checksums firmado, no solo un hash más fuerte. (Cuando los dos valores simplemente no cuadran, esa es otra cuestión, recorrida en por qué no coincide mi checksum.)

La decisión, de una pasada

Responde en orden y el algoritmo queda claro.

1. ¿Podría un adversario fabricar la entrada o sustituir el archivo? Si sí → SHA-256 o mejor en la capa del hash. Sin excepciones. MD5 y SHA-1 quedan fuera.
2. ¿Es una descarga pública o algo cercano a la seguridad? Trátalo como un «sí» a la pregunta 1: publica SHA-256, y fírmalo. Lo que derrota una referencia manipulada es la firma, no la longitud del hash.
3. ¿Solo detección de corrupción accidental, sin adversario, y controlas o confías en la fuente? Entonces MD5 está bien. Aunque un checksum no criptográfico (CRC32, xxHash) suele encajar mejor y ser más rápido, y para cualquier cosa nueva SHA-256 es el valor por defecto seguro de todas formas.
4. ¿Verificas un archivo que publicó otra persona? Usa el algoritmo con el que lo publicó. Si es solo MD5 y confías en la fuente y el canal, aún confirma la integridad accidental. Pero prefiere a quienes te dan SHA-256 y una firma.

Para calcular un hash tú mismo, la línea de comandos basta. En Linux: md5sum file, sha256sum file. En macOS las herramientas se llaman distinto: md5 -r file, shasum -a 256 file. En Windows PowerShell: Get-FileHash file -Algorithm SHA256. Para una comprobación rápida en el navegador, carga un archivo —o pega texto— en el generador de hash. Calcula un algoritmo a la vez, así que elige el que nombre tu referencia (MD5, SHA-256, SHA-512, SHA-3, BLAKE2b/BLAKE2s/BLAKE3 y más) y cambia de algoritmo para comparar. Ten en cuenta que da la salida en hexadecimal, no en el base64 que usa SRI, así que para un valor integrity="sha256-…" tendrás que convertir un lado.

Bajo las cuatro preguntas está la idea del principio. Es una decisión de modelo de amenaza, no un ranking. MD5 no está universalmente «roto» ni SHA-256 es universalmente «la respuesta». MD5 está roto para exactamente una cosa: resistir una colisión deliberada. Y esa única cosa es justo lo que un checksum de seguridad necesita, y lo que una comprobación de corrupción accidental no. Decide primero si hay un adversario. Y cuando lo hay, recuerda: el hash es la base, nunca toda la defensa.