MD5, SHA-1 y SHA-256: cómo elegir un hash
Un hash resume un archivo o mensaje en una cadena corta, pero esa palabra no responde por sí sola a una pregunta de seguridad. MD5, SHA-1 y SHA-256 tienen historias y propiedades distintas. Una coincidencia puede detectar que una descarga cambió si el valor esperado procede de un editor fiable. No prueba por sí sola quién publicó el archivo, no protege una base de datos de contraseñas y no transforma una descarga sin firma en auténtica. Antes de elegir algoritmo hay que separar esos trabajos.
El problema
Una función hash criptográfica recibe bytes de cualquier longitud y devuelve un resumen de tamaño fijo. Es determinista: los mismos bytes producen el mismo resultado. También está pensada para que cambiar bytes altere el resultado de modo difícil de predecir. Esto la hace útil para integridad, identificadores de artefactos, compilaciones y firmas. No significa que todos los algoritmos tengan la misma resistencia frente a un atacante deliberado.
MD5 produce 128 bits y SHA-1 produce 160. RFC 6151 y RFC 6194 documentan ataques de colisión y desaconsejan ambos cuando importa resistir colisiones. Una colisión consiste en construir dos entradas distintas con el mismo resumen. SHA-256 pertenece a SHA-2, especificada por FIPS 180-4, y es la opción normal entre estos tres para una comprobación de integridad nueva. Eso no equivale a autenticación de origen ni a almacenamiento seguro de contraseñas.
La pregunta inicial no es qué cadena parece más fuerte, sino qué decisión sostendrá. Detectar corrupción accidental, guardar un verificador de contraseña, acreditar que un editor autorizó una versión y firmar un documento son problemas diferentes. Cada uno cruza una frontera de confianza distinta y normalmente necesita una construcción distinta alrededor de un hash.
Ejemplo práctico
Supón que un proyecto publica `tool-4.2.zip` y un SHA-256 en su página HTTPS oficial de versiones. Descarga el archivo, calcula SHA-256 sobre los bytes descargados y compara todos los caracteres con el valor de esa página fiable. Si son diferentes, detente: puede estar incompleto, cambiado o ser otra versión. Si coinciden, los bytes locales coinciden con los bytes representados por la referencia publicada.
La conclusión tiene una condición decisiva. Si alguien puede reemplazar tanto el ZIP como el checksum de la página, seguirá existiendo coincidencia. La comparación no prueba la identidad del editor; prueba igualdad con la referencia conseguida. Un checksum copiado de un espejo desconocido, de un mensaje sin firma o de un buscador no tiene autoridad independiente. Obtén los metadatos desde un canal controlado por el editor y comprueba su identidad aparte.
El contraste con las contraseñas es importante. Un servicio no debe guardar un MD5, SHA-1 o SHA-256 directo de la contraseña. Los hashes generales rápidos permiten probar muchas claves candidatas tras una filtración. El almacenamiento necesita un esquema específico, con sal y coste adaptable de cálculo o memoria, seleccionado y configurado por el servicio. Comparar una descarga no es almacenamiento de contraseñas.
Procedimiento
Para verificar una descarga, identifica el nombre exacto, versión y editor antes de calcular nada. Descarga desde el sitio oficial de la versión cuando sea posible. Consigue el checksum en otra ubicación fiable o en un manifiesto firmado si se ofrece. Conserva juntos el nombre del archivo y su hash para no comparar por equivocación el ZIP 4.2 con el checksum de 4.1.
Calcula SHA-256 sobre el archivo original descargado, no sobre una carpeta extraída ni sobre un documento abierto y guardado por otra aplicación. Copia el resumen hexadecimal completo. La comparación debe rechazar una diferencia; no debe recortar, normalizar ni cambiar bytes silenciosamente. Si no coincide, elimina o pon en cuarentena la descarga y vuelve a obtenerla. No cambies el valor esperado para obtener una marca verde.
Cuando haga falta evidencia más fuerte del origen, sigue la guía de firma del editor. Una firma digital enlaza datos de una versión con una clave privada; se verifica con la clave pública asociada y con una decisión de confianza sobre ella. Comprueba la huella de la clave o certificado por un canal fiable, valida la firma sobre los metadatos correctos y revisa revocaciones o cambios de clave. La firma también necesita una distribución y una política de claves correctas.
Explicación técnica
La resistencia a colisiones pregunta si un atacante puede hallar dos entradas diferentes con el mismo hash. La resistencia a preimagen pregunta si, dado un hash, puede encontrar una entrada que lo genere. La resistencia a segunda preimagen pregunta si, dada una entrada, puede crear otra distinta con el mismo resultado. Son propiedades relacionadas, no intercambiables. Un protocolo debe declarar cuál necesita, en vez de tratar el tamaño del resumen como una puntuación universal.
Las colisiones prácticas conocidas hacen que MD5 y SHA-1 no sean apropiados para usos nuevos sensibles a colisiones: certificados, artefactos firmados o documentos. Un sistema heredado puede mostrar esos valores por compatibilidad o como identificador sin seguridad; su presencia no es una recomendación. Para una convención nueva de integridad, SHA-256 es preferible, aunque un protocolo concreto puede requerir otro algoritmo o formato estandarizado.
Un hash no contiene fecha, nombre de editor ni promesa de que un archivo sea seguro de ejecutar. El malware puede tener un SHA-256 válido si el atacante entrega también la referencia. Una firma válida dice que una clave concreta firmó datos; no sustituye comprobar que la clave pertenece al editor esperado ni evaluar que el software resulte adecuado para el entorno.
Errores frecuentes
Un error frecuente es considerar MD5 o SHA-1 aceptables porque una herramienta aún los ofrece. Su disponibilidad conserva interoperabilidad, no idoneidad de seguridad. Otro error es usar SHA-256 directamente para contraseñas por ser más reciente que MD5. La velocidad que sirve para resumir un archivo grande también facilita adivinar contraseñas sin conexión. Los esquemas de contraseñas añaden sal y coste deliberado, y su configuración depende del modelo de amenaza y el hardware.
También falla comparar solo un prefijo, aceptar cambios de mayúsculas o espacios sin entender el formato, o hashear una representación de texto en vez del archivo binario. Estos errores crean coincidencias engañosas u ocultan una diferencia. Emplea el formato publicado por el editor, retén el valor completo y repite el cálculo tras volver a descargar.
No publiques un checksum junto a una descarga y lo llames firma. Sirve ante corrupción accidental solo si la referencia ya es fiable. Si importa el origen, publica firmas verificables, instrucciones claras de distribución de claves y pasos de versión. No importes una clave desde un comentario, incidencia o mensaje pegado sin comprobarla de manera independiente.
Consideraciones
Hashear puede filtrar datos sobre entradas de poca entropía. Si un valor procede de un conjunto pequeño y predecible, alguien puede calcular candidatos y comparar resultados. No trates un hash como anonimización de nombres, correos, identificadores cortos o contraseñas. Las sales, los controles de acceso y la minimización de datos son controles distintos para riesgos distintos.
La integridad requiere además disciplina operativa. En la automatización de versiones registra algoritmo, hash completo, artefacto, versión, URL de origen y fecha. Genera el checksum desde la salida reproducible de compilación cuando sea viable y protege el canal de publicación. Prueba un artefacto modificado durante un simulacro para confirmar que una diferencia detiene el flujo. Esto reduce errores accidentales sin afirmar que un hash por sí solo autentique software.
Al usar un generador local, procesa solo material que tengas derecho a tratar. Para archivos sensibles, prefiere un comando local verificado del sistema operativo o un flujo interno aprobado. Una herramienta de navegador puede demostrar el cálculo, pero no acredita la procedencia de su entrada, la fiabilidad de la referencia copiada ni la política de seguridad del receptor.
Limitaciones
Esta guía es una comparación conceptual. No sustituye el procedimiento de verificación de un proveedor, una revisión criptográfica ni una respuesta a incidentes. No certifica una versión, clave, sitio, gestor de contraseñas o implementación hash. Los estándares y ataques evolucionan; en sistemas de impacto alto consulta la guía vigente del editor y los requisitos del protocolo aplicable.
Tampoco proporciona una clave privada, una contraseña utilizable ni instrucciones para eludir verificaciones. Si aparece una diferencia de checksum en software necesario para trabajar, conserva la evidencia requerida por tu organización, contacta con el editor oficial y usa una fuente conocida como buena. No distribuyas el artefacto sospechoso solo para que otros lo comparen.
Lista de comprobación
Elige SHA-256, no MD5 ni SHA-1, para un checksum general nuevo. Compara el resumen completo de los bytes exactos con una referencia obtenida mediante un canal fiable del editor. Una coincidencia significa igualdad con esa referencia, no prueba de identidad. Usa firmas y claves verificadas cuando importe el origen. Para contraseñas usa un esquema adaptativo con sal, nunca MD5, SHA-1 o SHA-256 desnudos. Guarda algoritmo, artefacto, versión, origen y resultado juntos, y detén el proceso ante cualquier diferencia.