SHA-256 produit une empreinte de 256 bits (32 octets) à partir de n’importe quelle donnée en entrée. Cette fonction de hachage cryptographique reste aujourd’hui résistante aux collisions connues et aux attaques par préimage. La question de confiance ne se pose pas de la même façon selon que l’on parle d’intégrité de fichiers, de signatures numériques ou de stockage de mots de passe.
Vitesse de SHA-256 : un atout pour l’intégrité, un défaut pour les mots de passe
Le reproche principal adressé à SHA-256 dans le contexte applicatif ne concerne pas sa solidité mathématique. Le problème est sa rapidité d’exécution.
A lire aussi : Sécurité OCR : limiter les risques grâce aux bonnes pratiques
Un algorithme de hachage rapide permet de vérifier l’intégrité d’un fichier ou de valider un commit Git en quelques millisecondes. Pour ces usages, la vitesse est une qualité. En revanche, cette même vitesse devient un handicap quand il s’agit de protéger des secrets.
Un attaquant qui dispose de matériel graphique performant peut tester un volume considérable de combinaisons par seconde contre un hash SHA-256. Les mots de passe courts ou prévisibles tombent en quelques minutes. SHA-256 n’a pas été conçu pour ralentir la force brute, et c’est exactement ce qu’on attend d’un algorithme de hachage de mots de passe.
A voir aussi : Sécurité du protocole WireGuard : est-il fiable et robuste ?
Les fonctions comme bcrypt, scrypt ou Argon2 intègrent un paramètre de coût qui rend chaque tentative volontairement lente. SHA-256 ne dispose pas de ce mécanisme. Utiliser SHA-256 pour stocker des mots de passe revient à verrouiller une porte avec un cadenas que l’on peut tester des milliards de fois par seconde.
SHA-256 pour la vérification d’intégrité : un usage toujours fiable
Quand un éditeur de logiciels publie un fichier accompagné de son empreinte SHA-256, l’objectif est de permettre à l’utilisateur de vérifier que le téléchargement n’a pas été altéré. Aucune collision exploitable n’a été démontrée sur SHA-256 à ce jour.
Git utilise historiquement SHA-1 pour identifier ses objets (commits, blobs, trees). Or SHA-1 a été cassé : des chercheurs ont prouvé qu’il est possible de produire deux fichiers différents générant le même hash SHA-1. Cette attaque par collision rend SHA-1 inadapté pour garantir l’authenticité d’un document.
SHA-256 ne souffre pas de cette vulnérabilité. Pour la vérification d’intégrité de fichiers, la signature de code ou la validation de paquets dans une chaîne d’approvisionnement logicielle, SHA-256 reste un choix solide.
Les cas où SHA-256 s’applique sans réserve
- Vérification de l’intégrité d’un fichier téléchargé (ISO, binaire, archive) en comparant l’empreinte publiée par l’éditeur
- Signature numérique de documents ou de certificats, où le hash sert de condensé avant chiffrement asymétrique
- Identification d’objets dans des systèmes de versionnement ou des registres distribués (blockchain, registres de paquets)
- Détection de modifications non autorisées dans des fichiers de configuration ou des journaux d’audit
Stockage de secrets : pourquoi la CNIL recommande autre chose que SHA-256
La recommandation de la CNIL pour le hachage de mots de passe exige un sel aléatoire unique par utilisateur et des paramètres de coût adaptés pour ralentir les attaques hors ligne. Un simple SHA-256, même accompagné d’un salt artisanal, ne répond pas à cette exigence.
Le sel empêche deux utilisateurs ayant le même mot de passe de produire la même empreinte. Le paramètre de coût, lui, impose un temps de calcul minimal par tentative. Sans ce frein, un attaquant ayant récupéré une base de données peut exploiter la vitesse brute de SHA-256 pour parcourir des dictionnaires entiers en un temps raisonnable.
Algorithmes adaptés au hachage de mots de passe
Bcrypt intègre nativement un sel et un facteur de coût réglable. Argon2, retenu comme vainqueur de la Password Hashing Competition, ajoute un paramètre de mémoire qui complique les attaques sur GPU. Argon2 est aujourd’hui le choix recommandé pour les nouvelles applications.
Scrypt occupe une position intermédiaire : il consomme davantage de mémoire que bcrypt, ce qui le rend plus résistant aux attaques matérielles spécialisées. Le choix entre ces trois algorithmes dépend des contraintes de l’environnement (ressources serveur, volume d’authentifications simultanées), mais aucun d’entre eux n’est SHA-256.
Entropie d’entrée et design applicatif : le hash ne compense pas un mauvais générateur
Un point rarement abordé dans les comparatifs concerne la qualité des données fournies au hash. Une vulnérabilité documentée a montré qu’un module de génération d’identifiants de session basé sur SHA-256 peut devenir prévisible si l’entropie d’entrée est insuffisante.
Autrement dit, SHA-256 transforme fidèlement ce qu’on lui donne. Si l’entrée est prévisible (horodatage seul, compteur séquentiel, graine pseudo-aléatoire faible), la sortie reste techniquement unique mais devient devinable par un attaquant qui reconstitue l’espace des entrées possibles.
Ce constat s’applique à tous les algorithmes de hachage. Un hash cryptographique solide ne remplace ni un générateur de nombres aléatoires cryptographiquement sûr, ni une architecture de sécurité cohérente. Le choix du hash est une brique, pas un mur.
SHA-256 face à la menace quantique : quelle perspective pour les applications actuelles
Les ordinateurs quantiques théoriquement capables d’exécuter l’algorithme de Grover réduiraient la résistance de SHA-256 de 256 bits à 128 bits effectifs. Ce niveau reste considéré comme suffisant pour la majorité des usages actuels.
Les infrastructures critiques (blockchain, signature de certificats racine) surveillent cette évolution de près. Pour une application web classique, la menace quantique sur SHA-256 ne justifie pas un changement immédiat. Les organismes de normalisation n’ont pas, à ce stade, retiré SHA-256 de leurs recommandations pour les usages d’intégrité et de signature.
SHA-256 mérite la confiance pour ce qu’il a été conçu à faire : produire une empreinte fiable et résistante aux collisions. Pour le stockage de mots de passe, la réponse est claire depuis plusieurs années : bcrypt ou Argon2 avec des paramètres de coût ajustés. Le vrai risque n’est pas dans l’algorithme lui-même, mais dans son utilisation hors de son périmètre de pertinence.
