Un hash produit une empreinte numérique à longueur fixe pour vérifier l’intégrité. Pour les mots de passe, il faut un sel et une fonction lente (Argon2/bcrypt/scrypt), pas MD5/SHA-256 seuls. Pour la falsification dans des systèmes critiques, combinez hash et signatures ou MAC (sinon, une altération peut passer sous le radar).
| Critère | Valeur |
|---|---|
| Longueur d’empreinte (MD5) | 128 bits (16 octets) |
| Longueur d’empreinte (SHA-256) | 256 bits (32 octets) |
| Objectif typique | Vérifier l’intégrité, pas protéger la confidentialité |
| Mots de passe | Sel + fonction lente (Argon2/bcrypt/scrypt) |
| Falsification | Hash + signatures ou MAC |
Un hash est une empreinte numérique à longueur fixe calculée à partir de données. En cybersécurité, il sert à vérifier l’intégrité, stocker des mots de passe de façon non réversible (avec sel et coût) et repérer des altérations. Le choix entre MD5, SHA-256, SHA-3 et des fonctions dédiées (bcrypt/Argon2/scrypt) dépend du risque et de la résistance aux collisions.
Définition d’un hash en cybersécurité : empreinte fixe et non‑réversibilité
Une fonction de hachage transforme une entrée de taille variable en une sortie de taille fixe, appelée empreinte. Le calcul est simple. La récupération de l’entrée d’origine, elle, est volontairement difficile.
La séparation entre calcul et reconstruction est le cœur du sujet : vous pouvez recalculer l’empreinte d’un fichier ou d’un message. En revanche, inverser le processus pour retrouver la donnée n’est pas l’objectif (et la difficulté dépend de l’algorithme).
Une empreinte SHA-256 fait 256 bits (soit 32 octets). MD5 produit 128 bits (soit 16 octets) : moins de bits, c’est moins d’espace pour absorber les collisions. En 2025, SHA-256 reste un choix courant pour l’intégrité, tandis que MD5 est généralement déconseillé.
Le test est simple : vous comparez l’empreinte attendue à celle recalculée. Si elles coïncident, vous avez une forte indication que la donnée n’a pas été modifiée. (Et si ça ne colle pas, vous arrêtez tout.)
Fonctionnement : compression et propriétés cryptographiques (préimage, collisions)
Une fonction de hachage applique des opérations mathématiques répétées pour “compresser” l’information en une empreinte. La sécurité repose sur plusieurs propriétés : résistance à la préimage (retrouver l’entrée), résistance aux secondes préimages et surtout résistance aux collisions (éviter deux entrées différentes avec le même hash).
Quand l’entrée change, l’empreinte change fortement. Cette diffusion rend la sortie imprévisible sans recalcul complet. Ensuite, on regarde les propriétés : si un attaquant peut retrouver l’entrée (préimage) ou fabriquer une collision, l’empreinte perd son rôle de preuve d’intégrité.
Pourquoi une collision affaiblit l’intégrité ? Parce qu’un attaquant peut viser deux contenus différents qui produisent la même empreinte. Votre système compare alors “hash attendu” et “hash recalculé”. Si la collision est exploitée, une donnée altérée peut être validée.
Le piège classique : confondre “ça calcule” et “c’est sûr”. Un hash peut être stable et facile à calculer, mais rester vulnérable si les propriétés attendues ne tiennent plus. SHA-256 est conçu pour rendre la recherche de collisions très coûteuse, et les faiblesses ont justement été exploitées lorsque certains algorithmes ont cessé d’être recommandés.
Selon l’objectif, les garanties ne sont pas les mêmes : pour l’intégrité, on privilégie la résistance aux collisions ; pour l’authentification, on ajoute souvent des mécanismes comme signatures ou MAC ; pour les mots de passe, on évite les fonctions rapides.
Hashes pour mots de passe : sel, coût et fonctions lentes (pas MD5/SHA-256 seuls)
Pour stocker des mots de passe, un hash “rapide” ne suffit pas. Il faut un mécanisme qui ralentit les attaques par force brute. On utilise un sel unique par utilisateur et une fonction de dérivation lente avec coût (Argon2, bcrypt, scrypt). Résultat : chaque essai devient plus cher pour l’attaquant.
Le sel est généralement stocké avec l’empreinte. Il n’a pas besoin d’être secret : il sert à empêcher les attaques par pré-calcul (comme les tables arc-en-ciel) et à limiter l’effet “même mot de passe = même empreinte” entre utilisateurs. Sans sel, deux personnes avec le même mot de passe obtiennent la même empreinte, ce qui facilite la corrélation.
Le coût (temps et/ou mémoire) augmente le temps de calcul par tentative. Un hash rapide type MD5 ou SHA-256 s’exécute à très grande vitesse : en cas de fuite de base, l’attaquant teste des millions d’essais hors-ligne. Avec Argon2/bcrypt/scrypt, on augmente le coût par essai et on réduit fortement le débit d’essais réalistes.
Argon2 est souvent recommandé dans les pratiques modernes. Le point pratique, c’est le paramétrage : vous ajustez le coût pour rester robuste face à l’évolution du matériel (GPU, ASIC). Puis vous prévoyez une évolution : quand vos serveurs supportent plus de coût, vous migrez progressivement.
- Sel unique par utilisateur (stocké avec le hash).
- Fonction lente (Argon2/bcrypt/scrypt) pour casser la vitesse d’attaque hors-ligne.
- Paramètres de coût ajustés selon vos contraintes CPU/mémoire.
Question simple : combien de temps doit prendre un calcul ? L’objectif est de rendre une tentative suffisamment coûteuse côté attaquant, tout en restant acceptable côté authentification (temps de réponse et charge applicative). On dimensionne donc le système, pas seulement l’algorithme.
MD5, SHA‑1, SHA‑256, SHA‑3 : comparer et comprendre pourquoi certains sont déconseillés
MD5 et SHA‑1 ont été très utilisés, puis abandonnés pour beaucoup d’usages cryptographiques à cause de faiblesses, notamment des collisions. SHA‑256 et SHA‑3 apportent de meilleures garanties pour l’intégrité. Le bon choix dépend du niveau de sécurité requis et du contexte (signature, intégrité, stockage).
MD5 produit 128 bits. Historiquement, il a été partout. Le problème : des collisions ont été démontrées, ce qui rend l’empreinte moins fiable comme preuve d’intégrité face à un adversaire. C’est pour ça qu’on l’écarte dans les scénarios de sécurité.
SHA‑1 produit 160 bits. Là aussi, les collisions ont conduit à un abandon progressif. Aujourd’hui, SHA‑1 ne reste présent que dans des cas où une politique interne ou une contrainte d’héritage l’impose.
SHA‑256 est très utilisé pour l’intégrité et les signatures. SHA‑3 (famille Keccak) offre une alternative robuste, selon les politiques cryptographiques et les exigences de conformité. En pratique, les équipes sécurité migrent vers SHA‑256/SHA‑3 et documentent les raisons (risque, conformité, compatibilité).
Réflexe anti-erreur : vérifier les recommandations actuelles et les exigences de votre cadre (RGPD, exigences internes, audits). Garder MD5 “pour faire simple” finit souvent par créer un risque de non-conformité.
Pour aller plus loin : NIST : fonctions de hachage cryptographiques et Wikipédia : fonction de hachage.
Sel et “hachage” vs “chiffrement” : quand l’empreinte suffit
Un hash n’est pas un chiffrement. Il ne protège pas la confidentialité : on ne cherche pas à récupérer la donnée originale. Le sel rend les empreintes uniques et limite les attaques par pré-calcul. Pour la confidentialité (lecture par des tiers), il faut du chiffrement ; pour l’intégrité, le hash est pertinent.
Malentendu fréquent : “si je hash, personne ne peut lire”. Non. Un hash sert à vérifier. Si un attaquant obtient les empreintes et que les mots de passe sont faibles, il peut tenter de deviner via des essais. C’est exactement pour ça qu’on utilise une fonction lente et un sel.
Pour la confidentialité, on chiffre. Pour l’intégrité, on calcule une empreinte et on la compare. Pour l’authentification et la résistance à la falsification, on ajoute des mécanismes complémentaires : signatures ou MAC. (Oui, ça fait plus de briques. Mais c’est ce qui empêche un “ça valide quand même” après manipulation.)
Le sel est généralement aléatoire et suffisamment long pour éviter des pré-calculs efficaces. Et surtout : “vérifier” n’est pas “cacher”. Comprendre cette différence évite de concevoir un système qui paraît sécurisé… jusqu’au bon modèle de menace.
Cas d’usage : intégrité de fichiers, blockchain, signatures et détection d’altération
Les hashes servent à vérifier que des données n’ont pas été modifiées : on compare l’empreinte recalculée à l’empreinte attendue. En blockchain, les structures de données utilisent des hachages pour relier les blocs et rendre les altérations visibles. Pour des garanties plus fortes contre la falsification, on combine hash et signatures ou MAC.
Intégrité de fichiers : un éditeur publie souvent des empreintes SHA‑256 pour ses téléchargements. Vous calculez l’empreinte localement, puis vous comparez. Si ça matche, vous réduisez le risque d’altération pendant le transfert. Sinon, vous stoppez.
Blockchain : le “chaînage” d’empreintes relie les blocs. Si un bloc change, l’empreinte change et la chaîne ne colle plus. Ce n’est pas magique : c’est une propriété de dépendance cryptographique. La robustesse dépend du choix de la fonction et de l’absence d’algorithmes obsolètes.
Signatures et MAC : le hash seul détecte une altération, mais ne suffit pas toujours à empêcher une falsification selon la manière dont l’empreinte est distribuée. Les signatures (ou MAC) servent à prouver l’origine et à empêcher qu’un attaquant remplace à la fois la donnée et l’empreinte attendue.
Dans les systèmes distribués, on publie et on vérifie des empreintes pour rendre la vérification reproductible. C’est aussi utile en audit : vous pouvez rejouer le calcul et contrôler la cohérence. Pour les mots de passe, c’est différent : on dérive et on ralentit, pas juste “on compare”.
Références utiles : OWASP : stockage des mots de passe et RFC 9106 : recommandations cryptographiques liées aux fonctions de hachage.
FAQ sur les hashes en cybersécurité
Comment savoir si un hash est encore considéré comme sûr pour l’intégrité ?
Vérifiez les recommandations actuelles (NIST/OWASP et politiques internes), l’absence de collisions exploitables pour l’usage visé, et la conformité à votre cadre. En pratique, privilégiez SHA‑256 ou SHA‑3 pour l’intégrité et évitez MD5/SHA‑1 dès que l’adversaire peut influencer les entrées.
Quel est le rôle du sel dans le stockage des mots de passe ?
Le sel rend chaque empreinte unique même si deux utilisateurs choisissent le même mot de passe. Il empêche les attaques par pré-calcul (tables arc-en-ciel) et limite la corrélation entre utilisateurs. Le sel est stocké avec l’empreinte, sans être un secret.
Pourquoi MD5 et SHA‑1 sont-ils déconseillés en cybersécurité ?
Parce que des collisions ont été démontrées et peuvent affaiblir la fiabilité de l’empreinte comme preuve d’intégrité contre un adversaire. Pour une intégrité robuste, on préfère des fonctions mieux étudiées et encore recommandées, comme SHA‑256 ou SHA‑3.
Quand faut-il utiliser Argon2, bcrypt ou scrypt plutôt qu’un simple SHA‑256 ?
Quand vous stockez des mots de passe. Les fonctions dédiées (Argon2/bcrypt/scrypt) sont conçues pour être lentes et résistantes aux attaques par force brute hors-ligne. SHA‑256 est trop rapide et devient un mauvais choix pour ralentir un attaquant.
Est-ce qu’un hash permet de récupérer la donnée originale ?
En théorie, certaines fonctions peuvent être inversées dans des cas faibles, mais l’objectif est justement de rendre la récupération impraticable. En pratique, un hash sert à vérifier, pas à récupérer. Pour récupérer l’original, il faut du chiffrement avec clé, pas un hash.
Combien de temps faut-il pour “forcer” un mot de passe avec un hash rapide vs une fonction lente ?
Ça dépend du matériel, du mot de passe et des paramètres. Mais la différence est massive : un hash rapide permet des millions à milliards d’essais par seconde, tandis qu’une fonction lente (avec coût et mémoire) réduit fortement le débit d’essais. L’enjeu est de rendre le temps de cracking non réaliste.
L’essentiel à retenir
- Un hash fournit une empreinte à longueur fixe pour vérifier l’intégrité, pas pour protéger la confidentialité.
- La sécurité dépend des propriétés cryptographiques (préimage, collisions) : un algorithme “qui marche” peut rester non sûr.
- Pour les mots de passe, utilisez un sel et une fonction lente (Argon2/bcrypt/scrypt), pas MD5/SHA‑256 seuls.
- MD5 et SHA‑1 sont généralement déconseillés ; SHA‑256 et SHA‑3 sont des choix plus robustes pour l’intégrité.
- Sel ≠ chiffrement : le sel rend les empreintes uniques et limite les attaques par pré-calcul.
- Pour se protéger contre la falsification, combinez hash avec signatures ou MAC, surtout dans des systèmes critiques.
- En pratique, publiez et vérifiez des empreintes avec des algorithmes recommandés pour réduire les risques d’altération.
