Les algorithmes SHA restent omniprésents dans les chaînes de déploiement, la vérification d’intégrité des images Docker et la signature de commits sur GitHub. L’enjeu pour un environnement de production ne se limite pas à choisir une variante SHA : il s’agit de savoir laquelle expose encore à des vulnérabilités connues, et à quel coût réel on migre vers une version plus robuste.
SHA-1 contre SHA-256 en production : ce que les données de sécurité montrent
| Critère | SHA-1 | SHA-256 | SHA-3 (Keccak) |
|---|---|---|---|
| Taille de l’empreinte | 160 bits | 256 bits | 256 bits (SHA3-256) |
| Résistance aux collisions | Cassée (collision démontrée par Google et CWI Amsterdam) | Aucune collision connue | Aucune collision connue |
| Statut NIST | Déprécié (SP 800-131A rév. 2, 2019) | Recommandé (FIPS 180-4) | Recommandé (FIPS 202) |
| Usage courant en production | Artefacts hérités, compatibilité TLS ancienne | Certificats TLS, intégrité de code, blockchain | Adoption croissante, post-quantique partiel |
Le point saillant : SHA-1 a été cassé en pratique, pas seulement en théorie. Google et l’institut CWI aux Pays-Bas ont généré deux fichiers PDF distincts produisant la même empreinte SHA-1. Cette démonstration a précipité le retrait de SHA-1 des certificats TLS par les principaux navigateurs dès 2017.
SHA-256 et SHA-3 ne présentent aucune collision publiée à ce jour. En revanche, leur coût de calcul diffère, ce qui pèse sur les pipelines de hachage intensif.
Vulnérabilités SHA-1 résiduelles dans les environnements TLS et Git
Le retrait officiel de SHA-1 des navigateurs ne signifie pas sa disparition des infrastructures. Des vestiges SHA-1 subsistent dans des piles réseau héritées, notamment autour de TLS 1.2 et de mécanismes de compatibilité anciens. Un serveur qui négocie encore TLS 1.2 avec des suites de chiffrement obsolètes peut, dans certaines configurations, tomber sur une chaîne de certificats signée en SHA-1.
Git illustre un autre angle mort. Le système de versioning utilise SHA-1 pour identifier chaque objet (commit, blob, arbre). Bien que le projet Git travaille sur une migration vers SHA-256, la majorité des dépôts GitHub en production restent indexés en SHA-1.
Le risque concret : une attaque par collision permettrait, en théorie, de substituer un objet Git par un autre ayant le même hash. Le scénario reste complexe à exploiter, mais il montre que le danger SHA-1 ne se limite pas aux certificats TLS.
Points de vérification pour un audit de dépendances
- Inspecter les certificats intermédiaires de la pile TLS avec un scanner de configuration (type testssl.sh) pour repérer toute signature SHA-1 résiduelle
- Vérifier la version de Git déployée et le mode de hachage actif sur les dépôts critiques, en identifiant si le flag SHA-256 est activé
- Passer en revue les actions GitHub (fichiers YAML) et les images Docker de base pour détecter des vérifications d’intégrité qui reposent encore sur SHA-1 ou MD5
Transition cryptographique NIST : le calendrier qui pèse sur SHA en production
Le NIST encadre la transition via la publication SP 800-131A. La révision 2, datée du 21 mars 2019, a formalisé la dépréciation de SHA-1 pour les signatures numériques. Un brouillon de révision 3, apparu en octobre 2024, introduit un plan plus explicite de retrait de SHA-1 dans la logique de modernisation des algorithmes hérités.
Cette trajectoire s’inscrit dans un mouvement plus large : le NIST prépare simultanément la standardisation d’algorithmes post-quantiques. La crypto-agilité, c’est-à-dire la capacité d’un système à changer d’algorithme sans refonte majeure, devient un critère d’architecture logicielle à part entière.
Pour les équipes en production, la conséquence directe est double. D’abord, tout nouveau service déployé doit utiliser SHA-256 au minimum. Ensuite, les systèmes existants qui dépendent encore de SHA-1 (même pour du hachage non cryptographique) accumulent une dette technique qui se transformera en dette de conformité à mesure que la révision 3 sera finalisée.
SHA-256 et SHA-3 : choisir selon le contexte de déploiement
SHA-256 couvre la grande majorité des besoins actuels : vérification d’intégrité de fichiers, signatures de code, hachage de données JSON dans les API, sécurisation des blocs dans une blockchain. Son adoption massive garantit une compatibilité large avec les bibliothèques, les scanners de vulnérabilités et les outils de CI/CD.
SHA-3, fondé sur une construction mathématique différente (Keccak, basé sur une éponge et non sur Merkle-Damgård), offre un avantage structurel : une attaque qui affaiblirait SHA-2 n’affecterait pas automatiquement SHA-3. Cette diversité algorithmique est le principal argument en faveur de SHA-3, plus que la performance brute.
Cas d’usage où SHA-3 se justifie
- Architectures orientées crypto-agilité, où l’on souhaite un algorithme de repli structurellement indépendant de SHA-2
- Projets soumis à des exigences réglementaires anticipant la transition post-quantique
- Systèmes embarqués utilisant des variantes légères comme SHAKE128 ou SHAKE256, qui permettent des empreintes de taille variable
- Hachage de données sensibles dans des scripts de déploiement où la surface d’attaque doit rester minimale sur le long terme
Pour un pipeline standard (Docker, GitHub Actions, vérification d’empreinte de paquets), SHA-256 reste le choix par défaut le plus pragmatique. SHA-3 se justifie quand l’architecture vise explicitement la résilience face à de futures percées cryptanalytiques.
La question qui détermine un choix de hash en production n’est pas « quel algorithme est le plus récent », mais « quel algorithme mon infrastructure peut-elle remplacer rapidement si une faille apparaît ». Les équipes qui intègrent cette logique de remplacement dès la conception de leurs pipelines évitent la dette cryptographique que SHA-1 a coûté à des milliers de systèmes ces dix dernières années.
