Hachage, chiffrement, encodage : ne plus confondre
Trois transformations qui se ressemblent et n'ont rien à voir. Savoir les distinguer évite les erreurs les plus fréquentes en sécurité.
Elouan
Série Cryptographie appliquée · article 1 sur 3
- Hachage, chiffrement, encodage : ne plus confondre
- Chiffrement symétrique et asymétrique
- Certificats et PKI
« Le mot de passe est chiffré en MD5 », « le fichier est crypté en Base64 »… Ces phrases reviennent sans arrêt, et elles sont fausses toutes les deux. Encodage, chiffrement et hachage transforment des données, mais pour des raisons complètement différentes. Les confondre mène à des erreurs graves, comme stocker des mots de passe d’une façon qui ne protège rien.
Trois transformations, trois objectifs
| Encodage | Chiffrement | Hachage | |
|---|---|---|---|
| But | Changer de format | Cacher le contenu | Calculer une empreinte |
| Secret nécessaire | Aucun | Une clé | Aucun (sauf HMAC) |
| Réversible | Oui, par tout le monde | Oui, avec la clé | Non |
| Taille de sortie | Proportionnelle à l’entrée | Proportionnelle à l’entrée | Fixe |
| Exemples | Base64, hexadécimal, URL encoding | AES, ChaCha20, RSA | SHA-256, SHA-3, Argon2 |
| Protège | Rien | La confidentialité | L’intégrité (et les mots de passe stockés) |
L’encodage : une question de format
L’encodage sert à représenter des données dans un format adapté à un usage : faire passer des données binaires dans un mail ou dans une URL, par exemple. Il n’y a aucun secret : n’importe qui peut revenir à l’original.
echo -n 'admin:Motdepasse1' | base64
# YWRtaW46TW90ZGVwYXNzZTE=
echo 'YWRtaW46TW90ZGVwYXNzZTE=' | base64 -d
# admin:Motdepasse1C’est ce que fait l’authentification HTTP « Basic » : l’identifiant et le mot de passe sont simplement encodés en Base64. Sans TLS, ils circulent donc en clair.
Base64 n’est pas une protection
Des mots de passe « encodés en Base64 » dans un fichier de configuration sont des mots de passe en clair. Les attaquants l’utilisent d’ailleurs pour masquer leurs commandes aux yeux des humains (le fameux powershell -enc …), pas pour les protéger.
Le chiffrement : cacher avec une clé
Le chiffrement rend les données illisibles pour qui ne possède pas la clé. Celui qui a la clé peut déchiffrer et retrouver l’original. Il protège la confidentialité : un disque chiffré volé, un échange TLS intercepté restent illisibles.
Il existe deux grandes familles, symétrique (une même clé pour chiffrer et déchiffrer) et asymétrique (une clé publique et une clé privée), détaillées dans l’article suivant.
« Crypter » ou « chiffrer » ?
En français, on dit chiffrer et déchiffrer. « Décrypter » existe : c’est retrouver le message sans avoir la clé, c’est-à-dire casser le chiffrement. « Crypter » n’a pas vraiment de sens.
Le hachage : une empreinte à sens unique
Une fonction de hachage prend une entrée de n’importe quelle taille et produit une empreinte (un « hash ») de taille fixe.
echo -n 'bonjour' | sha256sum
# 2cb4b1431b84ec15d35ed83bb927e27e8967d75f4bcd9cc4b25c8d879ae23e18
echo -n 'Bonjour' | sha256sum
# 9172e8eec99f144f72eca9a568759580edadb2cfd154857f07e657569493bc44Une seule lettre change, et l’empreinte n’a plus rien à voir : c’est l’effet avalanche.
Une bonne fonction de hachage doit être :
- à sens unique : impossible de retrouver l’entrée à partir de l’empreinte (résistance aux préimages) ;
- résistante aux collisions : impossible de trouver deux entrées qui ont la même empreinte.
| Fonction | Taille | Statut |
|---|---|---|
| MD5 | 128 bits | Collisions faciles depuis 2004. À n’utiliser que comme identifiant, jamais pour la sécurité. |
| SHA-1 | 160 bits | Première collision publique en 2017 (SHAttered). Abandonné pour les certificats et les signatures. |
| SHA-256 / SHA-512 (famille SHA-2) | 256 / 512 bits | Recommandés |
| SHA-3 | Variable | Recommandé, conception différente de SHA-2 |
À quoi sert un hash
- Vérifier l’intégrité : on compare l’empreinte d’un fichier téléchargé avec celle publiée par l’éditeur.
- Identifier un fichier : les bases de malwares (VirusTotal…) et les outils de forensic identifient les fichiers par leur SHA-256.
- Stocker des mots de passe sans les connaître, avec des fonctions adaptées (voir plus bas).
- Signer : on signe l’empreinte d’un document, pas le document entier (voir l’article sur l’asymétrique).
On ne « déchiffre » pas un hash
Les sites qui prétendent « déchiffrer du MD5 » ont simplement calculé à l’avance les empreintes de millions de mots de passe courants, et cherchent une correspondance. Ça marche sur motdepasse123, pas sur une phrase longue et aléatoire.
Stocker des mots de passe correctement
C’est l’application la plus importante, et la plus souvent ratée.
Un site ne doit jamais stocker les mots de passe en clair, ni chiffrés (car qui a la clé les a tous). Il stocke une empreinte, et compare l’empreinte de ce que l’utilisateur tape à celle qu’il a gardée.
Mais une fonction comme SHA-256 est conçue pour être rapide : une carte graphique en calcule des milliards par seconde. Un attaquant qui vole la base peut donc essayer des milliards de mots de passe par seconde. Il faut deux choses de plus :
- Un sel : une valeur aléatoire propre à chaque utilisateur, ajoutée au mot de passe avant le hachage. Deux utilisateurs avec le même mot de passe ont des empreintes différentes, et les tables précalculées deviennent inutiles.
- Une fonction volontairement lente, et si possible gourmande en mémoire, pour rendre chaque essai coûteux.
| Fonction | Remarque |
|---|---|
| Argon2id | Premier choix recommandé par l’OWASP, résistant aux attaques sur GPU |
| scrypt | Gourmand en mémoire |
| bcrypt | Très répandu, limité à 72 octets de mot de passe |
| PBKDF2 | Accepté (normes FIPS), avec un très grand nombre d’itérations |
La structure d’une empreinte bcrypt (exemple fictif)
$2b$12$KIXQ8nP3P1l4oV0sYkEoBu7yH9mE7uK1hYJpZ0bX3cF6mLqT9W2aS
On y lit l’algorithme (2b), le coût (12 = 2^12 itérations), puis le sel et l’empreinte. Tout est stocké ensemble, ce qui permet de vérifier le mot de passe plus tard.
À l’inverse, le hash NT de Windows (MD4 du mot de passe, sans sel, voir l’article sur NTLM) cumule les défauts : rapide et non salé. C’est pour ça qu’un mot de passe Windows faible est retrouvé très vite.
HMAC : hacher avec une clé
Un hash seul prouve qu’un message n’a pas changé… à condition qu’un attaquant ne puisse pas recalculer l’empreinte après l’avoir modifié. Le HMAC ajoute une clé secrète au calcul : seul celui qui possède la clé peut produire une empreinte valide. Il garantit donc l’intégrité et l’origine du message. On le retrouve dans TLS, dans les jetons JWT signés avec HS256, ou dans les signatures d’API.
L’article suivant détaille le chiffrement : symétrique et asymétrique.
L'essentiel
- Encodage : changer la représentation des données, sans secret et réversible par n'importe qui (Base64, hexadécimal, URL encoding). Ce n'est pas une protection.
- Chiffrement : rendre les données illisibles sans une clé. Réversible pour qui possède la clé. Protège la confidentialité.
- Hachage : calculer une empreinte de taille fixe, à sens unique. On ne « déchiffre » pas un hash. Sert à vérifier l'intégrité ou à comparer sans stocker l'original.
- Une bonne fonction de hachage résiste aux préimages (retrouver l'entrée) et aux collisions (trouver deux entrées de même empreinte). MD5 et SHA-1 ne résistent plus aux collisions.
- SHA-256 et SHA-3 sont adaptés à l'intégrité. Pour les mots de passe, il faut une fonction lente et salée : Argon2id, scrypt, bcrypt ou PBKDF2.
- Le sel est une valeur aléatoire propre à chaque mot de passe : deux mots de passe identiques donnent deux empreintes différentes, et les tables précalculées deviennent inutiles.
- HMAC = hachage avec une clé secrète : il prouve l'intégrité ET l'origine d'un message.
Idées reçues
Un développeur stocke les mots de passe en Base64 « pour qu'ils ne soient pas en clair ». Qu'en penses-tu ?
L'erreur courante. Dire que c'est mieux que rien.
En réalité. C'est équivalent au clair. Base64 est un encodage : n'importe qui le décode en une commande, sans clé. Les mots de passe doivent être hachés avec une fonction lente et salée (Argon2id, scrypt, bcrypt, PBKDF2).
Peut-on déchiffrer un hash MD5 ?
L'erreur courante. Répondre oui, puisque des sites le font.
En réalité. Non, un hash ne se déchiffre pas : c'est une fonction à sens unique. Les sites qui « déchiffrent » du MD5 ont simplement précalculé les empreintes de millions de mots courants et cherchent une correspondance. C'est pour ça qu'un mot de passe faible haché sans sel est retrouvé instantanément.
Pourquoi ne faut-il pas utiliser SHA-256 seul pour stocker des mots de passe ?
L'erreur courante. Dire que SHA-256 est sûr, donc adapté.
En réalité. SHA-256 est sûr pour l'intégrité, mais il est conçu pour être rapide : une carte graphique en calcule des milliards par seconde, ce qui rend les essais massifs très efficaces. Pour les mots de passe, on veut au contraire une fonction volontairement lente et coûteuse en mémoire, avec un sel : Argon2id, scrypt, bcrypt ou PBKDF2 avec beaucoup d'itérations.
MD5 est cassé : un fichier vérifié par son MD5 peut-il avoir été modifié sans que ça se voie ?
L'erreur courante. Répondre que MD5 ne sert plus à rien du tout.
En réalité. La faiblesse de MD5, ce sont les collisions : on peut fabriquer deux fichiers différents qui ont le même MD5. Un attaquant qui prépare les deux fichiers à l'avance peut donc tromper une vérification. Pour un contrôle d'intégrité face à un adversaire, on utilise SHA-256. MD5 reste utilisé comme identifiant rapide (par exemple pour rechercher un fichier dans une base de malwares), sans valeur de sécurité.
Tester ses connaissances
Références
- Serious Cryptography (2e éd.)Jean-Philippe Aumasson · No Starch Press
- Real-World CryptographyDavid Wong · Manning