Encodage, hachage, chiffrement : trois choses différentes

Distinguer Base64, hash et chiffrement.

◷ 25 minutesTravail sur votre machine

Objectifs

À la fin de cette leçon, vous saurez :

distinguer sans hésiter encodage (Base64), hachage (SHA-256) et chiffrement (AES) ;
démontrer les propriétés de chacun par l'expérience dans Node ;
expliquer pourquoi un mot de passe se HACHE et ne se chiffre jamais ;
choisir la bonne technique face à n'importe quel besoin réel.

🔗 Pour vous rafraîchir la mémoire : clés, certificats et autorités

Trois questions, trois outils

La confusion entre ces trois notions est si fréquente qu'elle mérite une leçon entière. La clé du tri : se poser la BONNE question.

Question posée	Outil	Réversible ?	Secret ?
« Comment transporter du binaire dans du texte ? »	encodage (Base64)	oui, sans clé, par tout le monde	aucun
« Comment vérifier une égalité sans stocker la donnée ? »	hash (SHA-256)	non — sens unique	pas applicable
« Comment rendre une donnée lisible seulement pour son destinataire ? »	chiffrement (AES)	oui, AVEC la clé	tout repose sur la clé

Trois outils, trois buts, zéro interchangeabilité. Vérifions chaque propriété par la pratique.

L'encodage : changer d'emballage, rien de plus

Dans le REPL Node :

> Buffer.from("bonjour").toString("base64")
'Ym9uam91cg=='
> Buffer.from("Ym9uam91cg==", "base64").toString()
'bonjour'

Aller-retour instantané, sans aucune clé. Ym9uam91cg== n'a RIEN de secret : n'importe qui décode en une ligne. Alors à quoi sert Base64 ? Au transport : faire passer des données binaires (image, certificat) dans des supports texte-only (email, JSON, URL). C'est un changement d'emballage, pas une protection.

⚠️ L'erreur classique, vue mille fois en revue de code : « j'ai encodé mon mot de passe en Base64, c'est sécurisé ». Non : c'est aussi protégé qu'un mot écrit à l'envers. Si vous voyez une chaîne se terminant par == dans une base de données, vous venez probablement de trouver des « mots de passe chiffrés » qui ne le sont pas.

Le hash : une empreinte à sens unique

const { createHash } = require("node:crypto");

function empreinte(texte) {
  return createHash("sha256").update(texte).digest("hex");
}

console.log(empreinte("mot-de-passe"));
// e38ad214943daad1d64c102faec29de4affe9da3d...  (64 caractères hexadécimaux)

Testons ses trois propriétés fondamentales :

empreinte("mot-de-passe") === empreinte("mot-de-passe");   // true  → DÉTERMINISTE
empreinte("mot-de-passe") === empreinte("Mot-de-passe");   // false → SENSIBLE au moindre bit
empreinte("x".repeat(10)) .length === empreinte("x".repeat(1e9)).length;
// true → TAILLE FIXE quelle que soit l'entrée

Et la propriété décisive : à sens unique. De l'empreinte, impossible mathématiquement de remonter à l'entrée — on peut seulement tester des candidats (« est-ce que ce mot de passe donne CETTE empreinte ? »). Le hash est un tampon encreur : chaque document a son empreinte unique, mais on ne redonne jamais le document depuis l'encre.

Usage vedette : vérifier une égalité sans stocker la donnée. Cas emblématique — les mots de passe :

À l'inscription   : stocker hash(mot de passe)          ← l'original disparaît
À la connexion    : comparer empreinte(saisi) avec empreinte(stockée)
                    identiques → c'est le bon utilisateur ✓

Même base volée, l'attaquant ne récupère que des empreintes. (Nuance honnête annoncée dès maintenant : les hash génériques rapides comme SHA-256 se prêtent aux attaques par dictionnaire ; en production, on utilise des algorithmes lents DÉDIÉS avec sel — bcrypt, argon2 — sujet détaillé au chapitre authentification.)

Autre usage quotidien : vérifier l'intégrité d'un téléchargement. Le site publie SHA-256 du fichier ; vous recalculez localement ; toute altération — même d'un octet — rend les empreintes différentes.

Le chiffrement : un coffre réversible AVEC clé

Le chiffrement transforme la donnée pour la rendre illisible, mais de façon RÉVERSIBLE — uniquement avec la clé :

// schéma conceptuel (Node fournit node:crypto pour le vrai)
chiffré = AES(données, cléSecrète);      // personne ne lit sans la clé
données = déchiffre(chiffré, cléSecrète); // relecture possible AVEC la clé

Sans la clé : inutilisable, même pour son propre auteur. Avec elle : retour intact. Usage : protéger une donnée QUI DEVRA ÊTRE RELUE — fichiers d'archive d'équipe, secrets de configuration chiffrés, données personnelles chez un prestataire. Le coût réel n'est pas le chiffrement lui-même mais la GESTION DES CLÉS : où vit la clé ? Qui y accède ? Que se passe-t-il si elle fuit ou disparaît ?

Reliez-le à TLS vu hier : HTTPS chiffre le trajet précisément parce que les données doivent être relues par le serveur — c'est du transport, donc du chiffrement.

Le tableau de décision — à internaliser définitivement

Besoin de RELIRE plus tard avec autorisation ?      → CHIFFREMENT (+ gestion de clés)
Besoin de VÉRIFIER une égalité / une intégrité ?    → HASH (sel + algorithme lent si mots de passe)
Besoin de TRANSPORTER du binaire dans du texte ?    → ENCODAGE (Base64) — jamais pour protéger

Un dernier test mental avant les exercices : « je veux que personne ne puisse jamais relire mes données » → ni encodage ni chiffrement ne conviennent ; il faut ne pas stocker, ou stocker uniquement des HASH.

Exercice

Classez chaque besoin : encodage, hash ou chiffrement ? Justifiez avec le tableau de décision.

Stocker en base les mots de passe des utilisateurs.
Inclure une petite image directement dans un fichier HTML.
Protéger une archive que l'équipe devra rouvrir plus tard.
Vérifier l'intégrité d'un fichier téléchargé dont le site publie l'empreinte.
Un collègue propose de « chiffrer les emails de réinitialisation en Base64 pour que personne ne les lise ». Quelles erreurs comptez-vous ?
Expérimentation : calculez empreinte("mot-de-passe") puis empreinte("mot-de-passE"). Comparez les deux résultats. Que démontrent-ils ?

Résumé

Base64 = emballage transparent (réversible sans clé) ; hash = empreinte irréversible ; chiffrement = coffre réversible avec clé.
Mot de passe → hash avec sel + algorithme lent dédié. Jamais Base64, jamais chiffrement simple.
La bonne question fait choisir le bon outil : relire ? vérifier ? transporter ?

Correction disponibleCherchez d’abord par vous-même.Voir la correction

Correction

Réponses détaillées

1. Hash (avec sel et algorithme lent type bcrypt/argon2 — détails au chapitre authentification). On n'a JAMAIS besoin de relire un mot de passe, seulement de vérifier celui saisi à la connexion : le tableau de décision pointe le hash.

2. Encodage Base64 (data-URI) : aucun secret à protéger, juste un transport binaire→texte pour éviter une requête HTTP supplémentaire.

3. Chiffrement : la relecture est nécessaire, donc réversibilité obligatoire — avec gestion sérieuse des clés (où sont-elles ? qui y accède ?).

4. Hash : le site publie SHA-256 du fichier original ; vous recalculez localement et comparez. Déterministe + sensible au moindre octet = toute altération est détectable sans posséder l'original.

Question 5. Deux erreurs cumulées : (a) Base64 n'est PAS du chiffrement — c'est un encodage réversible par n'importe qui en une ligne, donc « personne ne les lira » est faux ; (b) même avec du vrai chiffrement, l'email de réinitialisation contient généralement un lien à sens unique avec jeton éphémère — on ne chiffre pas le lien, on le rend inutilement devinable et à usage unique. La bonne pratique combine : jeton aléatoire à durée limitée, transporté en HTTPS (le chiffrement du trajet, déjà en place !).

Question 6.

empreinte("mot-de-passe") → e38ad214943daad1...
empreinte("mot-de-passE") → 8b7df143d91c7960...

Deux empreintes TOTALEMENT différentes pour un seul caractère modifié (s→S). C'est l'effet avalanche : impossible de deviner la proximité de deux entrées depuis leurs empreintes. Conséquence directe : un attaquant ne peut pas « approcher » progressivement votre mot de passe depuis le hash — chaque essai est un candidat complet, tout ou rien. C'est cette propriété qui rend le vol d'une base hachée peu exploitable... tant que les mots de passe eux-mêmes sont complexes.