Quand une base de données fuit, les mots de passe ne circulent presque jamais en clair. Les attaquants récupèrent des SHA hashes, ces empreintes cryptographiques censées protéger les identifiants. La question est de savoir ce que ces hashes révèlent réellement sur les utilisateurs, et dans quelle mesure ils résistent à une exploitation concrète.
SHA-1 contre SHA-256 contre bcrypt : résistance comparée face à une attaque par force brute
Tous les algorithmes de hachage ne se valent pas face à un attaquant motivé. Le cas LinkedIn, où des millions de hashes SHA-1 sans sel ont fuité, illustre à quel point le choix de l’algorithme change la donne.
| Algorithme | Sel (salt) | Temps estimé pour craquer un mot de passe courant | Niveau de protection |
|---|---|---|---|
| SHA-1 sans sel | Non | Quelques secondes à minutes | Très faible |
| SHA-1 avec sel | Oui | Heures à jours (selon longueur) | Faible |
| SHA-256 sans sel | Non | Minutes à heures | Faible |
| SHA-256 avec sel | Oui | Jours à semaines | Moyen |
| bcrypt (coût élevé) | Intégré | Mois à années | Élevé |
SHA-1 et SHA-256 sont des fonctions de hachage rapides, conçues pour vérifier l’intégrité de fichiers. Leur vitesse d’exécution se retourne contre la sécurité des mots de passe : un GPU moderne peut calculer des milliards de hashes SHA-1 par seconde.
bcrypt, à l’inverse, intègre un facteur de coût qui ralentit volontairement chaque calcul. C’est précisément cette lenteur qui rend l’attaque par force brute impraticable à grande échelle.
Données hashées et RGPD : pourquoi un SHA hash reste une donnée personnelle
Un réflexe courant en entreprise consiste à considérer les données hachées comme anonymisées. Les régulateurs européens et américains sont formels : un hash SHA ne suffit pas à anonymiser un jeu de données.
Les lignes directrices européennes sur la pseudonymisation précisent que les données hashées restent des données personnelles. La raison est technique : les hashes SHA échouent au critère dit « No Inference ». Un attaquant qui dispose du hash d’un mot de passe peut, par recoupement, déduire qu’un utilisateur réutilise le même mot de passe sur plusieurs services.
Du côté américain, les autorités considèrent désormais que des données hachées ne sont pas « anonymes » au sens juridique, car elles permettent des inférences sur les individus. Cette position vise explicitement les hashes utilisés en publicité, en analytics ou dans les data clean rooms.
Pour une entreprise soumise au RGPD ou à la directive NIS, stocker des identifiants sous forme de SHA hashes ne dispense d’aucune obligation de notification en cas de fuite.
Attaque par dictionnaire et rainbow tables : ce que révèle un SHA hash sans sel
Le sel (salt) est une valeur aléatoire ajoutée au mot de passe avant le hachage. Sans lui, deux utilisateurs ayant le même mot de passe produisent un hash identique. C’est ce mécanisme qui a rendu la fuite LinkedIn si exploitable : les hashes SHA-1 avaient été générés sans sel.
Deux vecteurs d’attaque principaux
- L’attaque par dictionnaire consiste à hacher des millions de mots de passe courants et à comparer les résultats aux hashes fuités. Un mot de passe comme « password » produit toujours le même hash SHA-1 : la correspondance est immédiate.
- Les rainbow tables sont des bases précalculées de correspondances texte-hash. Elles permettent de retrouver un mot de passe en quelques secondes, sans recalculer chaque hash. Le sel rend ces tables inutilisables, car chaque combinaison mot de passe + sel produit un hash unique.
- Le credential stuffing exploite les hashes cassés pour tester les mêmes couples identifiant/mot de passe sur d’autres services. Un seul hash SHA-1 compromis peut ouvrir l’accès à plusieurs comptes si l’utilisateur recycle ses mots de passe.
Le point commun de ces attaques : elles exploitent la prévisibilité des mots de passe humains. Un hash SHA-256 d’un mot de passe de 6 caractères reste trivial à casser, même avec un sel.
Vérification de fuite par k-anonymat : le SHA hash comme outil de protection
Le même algorithme SHA qui expose les mots de passe sert aussi à vérifier si un identifiant a fuité, sans le transmettre en clair. Les protocoles modernes de vérification, inspirés par l’API Pwned Passwords, utilisent une approche par k-anonymat.
Le principe : l’utilisateur calcule localement un hash SHA-1 de son mot de passe, puis n’envoie au serveur que les cinq premiers caractères de ce hash. Le serveur renvoie tous les hashes connus commençant par ce préfixe. La comparaison finale se fait en local, sur la machine de l’utilisateur.
Même une tranche de cinq caractères du hash suffit à révéler une information exploitable, mais le protocole de k-anonymat empêche le serveur de savoir quel hash exact est vérifié. C’est un compromis entre utilité et confidentialité qui repose entièrement sur la segmentation du hash.
Limites de cette approche
Le k-anonymat protège la requête, pas le hash lui-même. Si la base de données du service de vérification fuit à son tour, les hashes complets redeviennent vulnérables aux mêmes attaques par dictionnaire. La sécurité dépend toujours de la robustesse du mot de passe initial, pas du seul algorithme.
SHA hashes dans les dépôts Git : une fuite silencieuse de secrets
Les fuites de données ne se limitent pas aux bases de mots de passe. Des analyses récentes de dépôts Git publics montrent que des secrets (clés API, tokens, identifiants de service) se retrouvent régulièrement exposés dans l’historique des commits. Les hashes SHA-1 utilisés par Git pour identifier chaque commit ne protègent en rien le contenu versionné.
Un développeur qui supprime un fichier contenant un mot de passe ne supprime pas le hash de ce commit. Le secret reste accessible dans l’historique complet du dépôt. Un simple parcours de l’arbre Git suffit à extraire des identifiants en texte brut.
Ce vecteur de fuite concerne aussi bien les projets open source que les dépôts privés dont l’accès est mal configuré. L’empreinte SHA du commit n’offre ici aucune couche de protection : elle sert d’index, pas de chiffrement.
La capacité d’un SHA hash à protéger une information dépend de trois facteurs : l’algorithme choisi, la présence d’un sel et la complexité du mot de passe initial. Un hash rapide sans sel sur un mot de passe courant équivaut, en pratique, à du texte brut.
Les cadres réglementaires européens et américains confirment cette réalité en refusant de considérer les données hashées comme anonymes. Le hash SHA n’est pas une garantie de sécurité, c’est un maillon dont la solidité dépend entièrement de son implémentation.
