Outils de développement · Calculateur de hachage SHA
SHA-1 Les collisions expliquées : ce qui est toujours sûr et ce qui doit être migré
· Pourquoi c'est important
sha-256 cryptographie sécurité
Un scanner signale SHA-1 et la direction demande à quel point c'est urgent. Cet article explique ce qu'une attaque par collision fait et n'interrompt pas, où SHA-1 est toujours toléré et comment planifier une migration.
Le scanner indique que SHA-1 est cassé, mais cassé pour quoi ? La question qui décide de l'urgence de la migration
Un scanner de sécurité réseau signale SHA-1 sur votre infrastructure. La direction demande à quel point c'est urgent. La réponse dépend entièrement de la raison pour laquelle vous utilisez SHA-1, et cette question révèle si vous avez un problème de conformité, un problème de sécurité actif ou simplement un artefact hérité qui doit être catalogué. SHA-1 est cryptographiquement brisé : des démonstrations universitaires ont prouvé des collisions. Mais « cassé » signifie différentes choses selon le rôle que joue SHA-1 dans votre système.
Un hachage cryptographique sert à différentes fins dans différents contextes. Parfois, il s’agit d’une somme de contrôle protégeant contre une corruption accidentelle. Parfois, il s'agit d'un engagement, comme une somme de contrôle de téléchargement publiée qui permet aux utilisateurs de vérifier qu'ils ont reçu le fichier prévu par l'éditeur. Parfois, il fait partie d'une chaîne de signature ou de certificat, dans laquelle un attaquant disposant de suffisamment de contrôle peut produire deux documents, tous deux significatifs, partageant le même hachage, et ainsi forger une authentification. La gravité d'une collision SHA-1 dépend essentiellement du rôle de SHA-1 dans votre système.
Collision versus préimage : pourquoi les attaques démontrées publiquement ciblent les collisions et ce que cela signifie pour un hachage existant
Une attaque par collision produit deux entrées différentes avec la même sortie. Un attaquant ne trouve pas de message haché à une valeur prédéterminée : ce serait une attaque par pré-image, et cela reste irréalisable pour SHA-1. Au lieu de cela, une attaque par collision signifie que l’attaquant peut créer deux documents hachés de manière identique. Si un système s’appuie sur un hachage pour prouver que deux choses sont identiques, une collision brise cette preuve. L'attaquant doit créer les deux entrées, ce qui nécessite du temps et des calculs, mais le résultat est deux éléments distincts apparaissant identiques sous le hachage.
Une attaque par pré-image signifierait qu'un attaquant pourrait prendre un hachage SHA-1 publié et trouver une entrée correspondant à celui-ci. Ce n’est pas ainsi que fonctionnent les attaques SHA-1. Si vous disposez d'un référentiel de résumés SHA-1 et que vous vous demandez si un fichier leur correspond réellement, une attaque par collision n'est pas une menace. La menace est de savoir si une personne ayant accès à votre référentiel pourrait falsifier un fichier différent pour le même résumé. Dans la plupart des cas, cela n’est pas réaliste sans le contrôle du processus de hachage lui-même. Le modèle d’attaque spécifique compte autant que l’algorithme.
Les démonstrations 2017 — deux fichiers différents avec le même SHA-1, décrits qualitativement, et le travail de préfixe choisi qui a suivi
L'attaque SHAttered de 2017 a démontré une collision pratique : deux fichiers PDF différents avec le même résumé SHA-1. Les chercheurs ont soigneusement construit les deux fichiers, les transformant en PDF valides lors de leur collision. Le travail a nécessité des efforts informatiques substantiels et du matériel spécialisé. Ce qui compte, c'est que cela ait été possible : la résistance aux collisions qui justifie l'utilisation de SHA-1 pour la sécurité a disparu. L’attaque a prouvé que deux documents sémantiquement différents pouvaient partager un résumé, ce qui brise tout système qui fait confiance au résumé comme preuve d’identité.
L'attaque qui a suivi dans 2020, appelée "SHA-1 est une pagaille", a franchi l'étape suivante : des collisions de préfixes choisis. Cette variante signifie qu'un attaquant peut prendre deux documents arbitraires, concaténer des suffixes différents à chacun et produire une collision. C'est l'attaque dangereuse pour les signatures et les certificats. Un attaquant n’est pas obligé de repartir de zéro ; ils peuvent entrer en collision avec deux documents significatifs et distincts. Cela brise le modèle de sécurité de tout système qui signe les résumés SHA-1. L’attaquant peut produire deux documents dont le hachage est identique et qui signifient tous deux quelque chose de différent.
Là où SHA-1 est inacceptable : signatures, certificats et tout ce qu'un attaquant peut influencer des deux côtés de
La distinction est importante car SHA-1 est toujours tolérable dans certains rôles et absolument inacceptable dans d'autres. Dans Git, SHA-1 est utilisé comme adresse de contenu, c'est-à-dire le nom d'un instantané particulier de fichiers. Git n'utilise pas SHA-1 pour l'authentification ; c'est un système de dénomination. Un attaquant pourrait théoriquement calculer deux états de référentiel différents avec le même ID, mais cela nécessite de contrôler l'ensemble du processus de création de contenu et de diffuser les deux versions avant que quiconque ne s'en aperçoive. Pour la plupart des équipes, ce niveau de contrôle des attaquants ne constitue pas un modèle de menace. C'est pourquoi Git passe délibérément à SHA-256 plutôt que de le traiter comme une urgence.
Dans un scénario de vérification de téléchargement Web, un éditeur publie un fichier et sa somme de contrôle SHA-1 sur le même serveur. Un attaquant qui compromet ce serveur contrôle à la fois le fichier et la somme de contrôle. Ils peuvent télécharger un fichier et publier son SHA-1, et aucune collision n'est requise. Si la somme de contrôle est publiée ailleurs (sur un VPN sécurisé, imprimée dans un e-mail signé, publiée dans une infrastructure différente), alors l'attaquant doit entrer en collision, et cela devient irréalisable. La somme de contrôle est aussi fiable que son canal. C'est pourquoi la vérification du téléchargement nécessite plus qu'un hachage.
Là où cela persiste avec moins de risques : identification du contenu dans des contextes non conflictuels et transition par étapes de Git vers SHA-256
Pour les signatures et les certificats, SHA-1 est indéfendable. Un certificat est enchaîné à partir d’une racine approuvée. Si une autorité de certification signe deux certificats différents en utilisant le même résumé SHA-1, une attaque par collision permet à un attaquant de falsifier l'un ou l'autre. Ce n’est pas théorique : des attaques contre des AC intermédiaires ont été documentées. Tout schéma de signature qui s'appuie sur SHA-1 est potentiellement falsifiable par un attaquant disposant de suffisamment de ressources. Tous les principaux fournisseurs de navigateurs et de systèmes d'exploitation ont rendu obsolète SHA-1 dans les certificats. Les nouveaux certificats doivent utiliser SHA-256. Les éditeurs de plateformes se sont exprimés clairement car la menace est réelle et immédiate.
Le NIST, l'organisme de normalisation américain, a fixé un calendrier explicite. À partir du 2024, SHA-1 ne doit plus être utilisé pour de nouvelles applications. À compter du 2030, SHA-1 devrait être entièrement retiré des systèmes fédéraux. Il ne s’agit pas d’une vague dépréciation ; il s'agit d'un mandat concret pour les entrepreneurs gouvernementaux et d'un signal adressé à l'industrie. Le respect du calendrier du NIST garantit que vos systèmes gardent une longueur d'avance sur la courbe de dépréciation plutôt que de se bousculer après la date limite.
Les preuves du référentiel soutiennent la dépréciation de SHA-1, et non une publication NIST non lue ou une date de retrait
La source du référentiel documente SHA-1 comme interopérabilité héritée et les noms démontrent le travail de collision, mais il ne contient pas de calendrier de retrait des organismes de normalisation. Cette section corrige donc les grandes lignes en traitant la dépréciation comme un problème d'inventaire technique plutôt que de citer un numéro de publication non lu ou une date de conformité.
Pour les environnements contrôlés par des règles, consultez l'autorité régissant ce déploiement et enregistrez le document exact examiné. Les preuves de produit soutiennent ici une action plus précise : garder SHA-1 disponible pour reproduire les valeurs existantes, l'étiqueter comme inadapté à de nouvelles utilisations de sécurité et calculer un remplacement SHA-256 partout où le protocole environnant permet la migration.
Exemple concret : une liste de contrôle de migration appliquée à une ancienne page de vérification de téléchargement
Un chemin de migration depuis SHA-1 commence généralement par un inventaire : où SHA-1 est-il utilisé ? Certificats et signatures ? Priorité immédiate. Dépôts Git et adressage de contenu ? Priorité moyenne, suivez le rythme de migration Git. Sommes de contrôle publiées pour les téléchargements ? Cela dépend du modèle de confiance. Sommes de contrôle internes pour la déduplication ou l'archivage ? Priorité moindre, plus de temps pour la planification. La phase d'inventaire révèle la véritable surface et vous aide à établir des priorités en fonction du risque réel plutôt que de l'urgence abstraite.
Pour chaque rôle, la migration est différente. Les certificats sont immédiatement mis à niveau vers SHA-256. Les référentiels Git se mettent progressivement en place dans les références SHA-256 tout en conservant SHA-1 pour une compatibilité ascendante. Les sommes de contrôle de téléchargement commencent à être publiées dans SHA-1 et SHA-256, puis finalement seulement dans SHA-256. Les anciens résumés SHA-1 dans une base de données de somme de contrôle peuvent être vérifiés avec le calculateur de hachage ToolAcre SHA, et les nouvelles entrées doivent utiliser SHA-256. L'outil prend en charge les deux côtés de la transition, vous permettant de vérifier les anciens hachages et d'en créer de nouveaux.
À retenir : SHA-1 à titre de comparaison, SHA-256 pour les nouveaux travaux — le calculateur de hachage ToolAcre SHA inclut SHA-1 afin que les résumés existants puissent être vérifiés, et non comme une approbation
Pour la plupart des organisations, la migration ne consiste pas à « désactiver SHA-1 demain ». Il s'agit de « comprendre où il est utilisé, hiérarchiser les rôles critiques en matière de sécurité et avoir un plan pluriannuel ». Un référentiel Git avec des années de commits SHA-1 devrait évoluer progressivement, avec des outils qui gèrent les deux. Une infrastructure de certificats devrait déjà avoir migré. Les sommes de contrôle publiées doivent être à double algorithme pendant une fenêtre de transition. La migration progressive réduit les changements brusques et donne aux systèmes le temps de s'adapter à la nouvelle réalité.
Le calculateur de hachage ToolAcre SHA fournit les deux côtés de cette transition. Vous pouvez vérifier les résumés SHA-1 existants de vos anciens systèmes pour confirmer qu'un fichier leur correspond. Vous pouvez calculer les hachages SHA-256 pour commencer à publier le chemin de migration. L'outil ne prétend pas que SHA-1 est sûr ; il le qualifie de cassé et explique pourquoi. Mais il vous permet de travailler avec les hachages hérités que vous devez encore conserver pendant que vous construisez le pont vers SHA-256 et planifiez votre dépréciation.