Herramientas de desarrollo · Calculadora de hash SHA
SHA-1 Explicación de las colisiones: qué sigue siendo seguro y qué se debe migrar
· Por qué es importante
sha-256 criptografía seguridad
Un escáner marca SHA-1 y la gerencia pregunta qué tan urgente es. Esta publicación explica qué se rompe y qué no se rompe un ataque de colisión, dónde todavía se tolera SHA-1 y cómo planificar una migración.
El escáner dice que SHA-1 está roto, pero ¿para qué? La cuestión que decide la urgencia de la migración
Un escáner de seguridad de red marca SHA-1 en su infraestructura. La gerencia pregunta qué tan urgente es. La respuesta depende completamente de para qué esté utilizando SHA-1, y esa pregunta revela si tiene un problema de cumplimiento, un problema de seguridad activo o simplemente un artefacto heredado que debe catalogarse. SHA-1 está criptográficamente roto: las demostraciones académicas han demostrado colisiones. Pero "roto" significa cosas diferentes según el papel que desempeña SHA-1 en su sistema.
Un hash criptográfico tiene diferentes propósitos en diferentes contextos. A veces es una suma de control que protege contra la corrupción accidental. A veces es un compromiso, como una suma de verificación de descarga publicada que permite a los usuarios verificar que recibieron el archivo que pretendía el editor. A veces es parte de una cadena de firmas o certificados, donde un atacante con suficiente control puede producir dos documentos, ambos significativos, que comparten el mismo hash y, por lo tanto, falsificar la autenticación. La gravedad de una colisión SHA-1 depende fundamentalmente de cuál de estas funciones tiene SHA-1 en su sistema.
Colisión versus preimagen: por qué los ataques demostrados públicamente tienen como objetivo colisiones y qué significa eso para un hash existente
Un ataque de colisión produce dos entradas diferentes con la misma salida. Un atacante no encuentra un mensaje con un valor predeterminado; eso sería un ataque previo a la imagen y sigue siendo inviable para SHA-1. En cambio, un ataque de colisión significa que el atacante puede crear dos documentos con hash idéntico. Si un sistema se basa en un hash para demostrar que dos cosas son iguales, una colisión rompe esa prueba. El atacante debe crear ambas entradas, lo que requiere tiempo y cálculo, pero el resultado son dos cosas distintas que aparecen idénticas bajo el hash.
Un ataque de preimagen significaría que un atacante podría tomar un hash SHA-1 publicado y encontrar alguna entrada que coincida con él. No es así como funcionan los ataques SHA-1. Si tiene un repositorio de resúmenes SHA-1 y le preocupa si un archivo realmente coincide con ellos, un ataque de colisión no es la amenaza. La amenaza es si alguien con acceso a su repositorio podría falsificar un archivo diferente en el mismo resumen. En la mayoría de los casos, esto tampoco es realista sin el control del propio proceso de hash. El modelo de ataque específico importa tanto como el algoritmo.
Las demostraciones de 2017: dos archivos diferentes con el mismo SHA-1, descritos cualitativamente, y el trabajo de prefijo elegido que siguió
El ataque SHAttered de 2017 demostró una colisión práctica: dos archivos PDF diferentes con el mismo resumen SHA-1. Los investigadores construyeron cuidadosamente ambos archivos, diseñándolos para que fueran PDF válidos mientras colisionaban. El trabajo requirió un esfuerzo computacional sustancial y hardware especializado. Lo que importa es que fue posible: la resistencia a la colisión que justifica el uso de SHA-1 por seguridad desapareció. El ataque demostró que dos documentos semánticamente diferentes podrían compartir un resumen, lo que rompe cualquier sistema que confíe en el resumen como prueba de identidad.
El ataque que siguió en 2020, llamado "SHA-1 es un desastre", dio el siguiente paso: colisiones de prefijos elegidos. Esta variante significa que un atacante puede tomar dos documentos arbitrarios, concatenar diferentes sufijos para cada uno y producir una colisión. Este es el peligroso ataque a firmas y certificados. Un atacante no tiene que empezar desde cero; pueden colisionar dos documentos distintos y significativos. Eso rompe el modelo de seguridad de cualquier sistema que firme resúmenes SHA-1. El atacante puede producir dos documentos que tengan el mismo hash y ambos signifiquen algo diferente.
Donde SHA-1 es inaceptable: firmas, certificados y cualquier cosa que un atacante pueda influir en ambos lados de
La distinción es importante porque SHA-1 sigue siendo tolerable en algunos roles y absolutamente inaceptable en otros. En Git, SHA-1 se utiliza como dirección de contenido: un nombre para una instantánea particular de archivos. Git no utiliza SHA-1 para la autenticación; es un esquema de nombres. En teoría, un atacante podría calcular dos estados de repositorio diferentes con el mismo ID, pero eso requiere controlar todo el proceso de creación de contenido y enviar ambas versiones antes de que alguien se dé cuenta. Para la mayoría de los equipos, ese nivel de control del atacante no es el modelo de amenaza. Es por eso que Git está haciendo la transición a SHA-256 deliberadamente en lugar de tratarlo como una emergencia.
En un escenario de verificación de descarga web, un editor publica un archivo y su suma de verificación SHA-1 en el mismo servidor. Un atacante que compromete ese servidor controla tanto el archivo como la suma de comprobación. Pueden cargar un archivo y publicar su SHA-1, y no se requiere colisión. Si la suma de verificación se publica en otro lugar (en una VPN segura, se imprime en un correo electrónico firmado, se publica en una infraestructura diferente), entonces el atacante debe colisionar y eso se vuelve inviable. La suma de control es tan confiable como su canal. Es por eso que la verificación de descarga requiere más que un hash.
Donde persiste con menos riesgo: identificación de contenido en entornos no conflictivos y transición por etapas de Git a SHA-256
Para firmas y certificados, SHA-1 es indefendible. Un certificado se encadena desde una raíz confiable. Si una CA firma dos certificados diferentes utilizando el mismo resumen SHA-1, un ataque de colisión permite que un atacante falsifique cualquiera de ellos. Esto no es teórico: se han documentado ataques contra CA intermedias. Cualquier esquema de firma que dependa de SHA-1 es potencialmente falsificable por un atacante con suficientes recursos. Todos los principales proveedores de navegadores y sistemas operativos han dejado de utilizar SHA-1 en los certificados. Los nuevos certificados deben utilizar SHA-256. Los proveedores de plataformas han hablado claramente porque la amenaza es real e inmediata.
NIST, el organismo de normalización de EE. UU., ha establecido un cronograma explícito. A partir de 2024, SHA-1 no debe usarse para ninguna aplicación nueva. A partir de 2030, se espera que SHA-1 se retire por completo de los sistemas federales. Esta no es una vaga desaprobación; es un mandato concreto para los contratistas gubernamentales y una señal para la industria. Seguir el cronograma del NIST garantiza que sus sistemas se mantengan a la vanguardia de la curva de obsolescencia en lugar de luchar después de la fecha límite.
La evidencia del repositorio respalda la desuso de SHA-1, no una publicación del NIST no leída ni una fecha de retiro
Los documentos fuente del repositorio SHA-1 como interoperabilidad heredada y los nombres demostraron trabajo de colisión, pero no contiene un cronograma de retiro del organismo de estándares. Por lo tanto, esta sección corrige el esquema al tratar la obsolescencia como un problema de inventario de ingeniería en lugar de citar un número de publicación no leído o una fecha de cumplimiento.
Para entornos controlados por políticas, consulte a la autoridad que rige esa implementación y registre el documento exacto revisado. La evidencia del producto aquí respalda una acción más limitada: mantener SHA-1 disponible para reproducir valores existentes, etiquetarlo como inadecuado para nuevos usos de seguridad y calcular un reemplazo SHA-256 siempre que el protocolo circundante permita la migración.
Ejemplo resuelto: una lista de verificación de migración aplicada a una página de verificación de descarga heredada
Una ruta de migración desde SHA-1 generalmente comienza con un inventario: ¿dónde se usa SHA-1? ¿Certificados y firmas? Prioridad inmediata. ¿Repositorios de Git y direccionamiento de contenidos? Prioridad media, siga el ritmo de migración de Git. ¿Sumas de comprobación publicadas para descargas? Depende del modelo de confianza. ¿Sumas de verificación internas para deduplicación o archivo? Menor prioridad, más tiempo para planificar. La fase de inventario revela la superficie real y le ayuda a priorizar en función del riesgo real en lugar de la urgencia abstracta.
Para cada rol, la migración es diferente. Los certificados se actualizan a SHA-256 inmediatamente. Los repositorios de Git incorporan gradualmente las referencias SHA-256 mientras se mantienen SHA-1 para compatibilidad con versiones anteriores. Las sumas de comprobación de descarga comienzan a publicarse tanto en SHA-1 como en SHA-256 y, finalmente, solo en SHA-256. Los resúmenes heredados de SHA-1 en una base de datos de suma de verificación se pueden verificar con la calculadora de hash ToolAcre SHA, y las nuevas entradas deben usar SHA-256. La herramienta admite ambos lados de la transición, lo que le permite verificar hashes antiguos y crear otros nuevos.
Para llevar: SHA-1 para comparación, SHA-256 para trabajo nuevo: la calculadora de hash SHA de ToolAcre incluye SHA-1 para que se puedan verificar los resúmenes heredados, no como un respaldo
Para la mayoría de las organizaciones, la migración no es "desactivar SHA-1 mañana". Se trata de "comprender dónde se utiliza, priorizar las funciones críticas para la seguridad y tener un plan plurianual". Un repositorio Git con años de confirmaciones SHA-1 debería realizar una transición gradual, con herramientas que manejen ambas. Una infraestructura de certificados ya debería haber migrado. Las sumas de verificación publicadas deben ser de algoritmo dual durante una ventana de transición. La migración gradual reduce los cambios importantes y da tiempo a los sistemas para adaptarse a la nueva realidad.
La calculadora de hash SHA de ToolAcre proporciona ambos lados de esa transición. Puede verificar los resúmenes SHA-1 existentes de sus sistemas heredados para confirmar que un archivo coincida con ellos. Puede calcular SHA-256 hashes para comenzar a publicar la ruta de migración. La herramienta no pretende que SHA-1 sea segura; lo etiqueta como roto y explica por qué. Pero le permite trabajar con los hashes heredados que aún necesita mantener mientras construye el puente hacia SHA-256 y planifica su obsolescencia.