Chapitre 3.1 — Encoder ≠ hacher ≠ chiffrer

⏱️ TL;DR — Trois opérations qu’on confond tout le temps, avec des conséquences graves. Encoder (Base64, URL-encode, hex) transforme une donnée pour la transporter : c’est réversible et non secret — Base64 n’est pas du chiffrement. Hacher (SHA-256, argon2) produit une empreinte à sens unique : on ne « déchiffre » pas un hash. Chiffrer (AES, RSA) rend une donnée illisible mais réversible avec une clé. Confondre les trois mène à des désastres : « chiffrer » un mot de passe (au lieu de le hacher), croire que Base64 protège un secret, ou vouloir « déchiffrer » un hash. Choisis l’outil selon le besoin.

🎯 Objectifs

• Définir précisément encoder, hacher, chiffrer et leurs propriétés.
• Reconnaître qu’un encodage (Base64…) n’offre aucune confidentialité.
• Savoir quand utiliser un hachage (à sens unique) vs un chiffrement (réversible).
• Éviter les confusions classiques qui créent des failles.

Trois opérations, trois buts

La question qui tranche : veux-tu récupérer la donnée d’origine ?

• Non, tu veux juste vérifier une correspondance (mot de passe) ou une intégrité → hacher.
• Oui, un jour tu devras la relire en clair (un numéro à traiter, un token à valider) → chiffrer.
• Tu veux juste la représenter dans un format sûr pour le transport (JSON, URL) → encoder.

Encoder : réversible et NON secret

Encoder transforme une donnée d’un format à un autre selon un schéma public. Base64, par exemple, représente des octets en caractères ASCII sûrs pour un email, une URL ou un data:. C’est réversible par n’importe qui, sans clé ni secret :

// Base64 n'est PAS du chiffrement — c'est public et reversible
const secret = "motdepasse123"
const encode = btoa(secret)      // "bW90ZGVwYXNzZTEyMw==" (navigateur)
const decode = atob(encode)      // "motdepasse123" — n'importe qui le fait

⚠️ Piège — L’erreur la plus courante et la plus dangereuse : croire que Base64 « cache » ou « protège » une donnée. Voir Authorization: Basic dXNlcjpwYXNz ou un token Base64 dans une réponse ne signifie rien en termes de secret — c’est décodable en une ligne. Un « secret encodé en Base64 » est un secret en clair. Base64 sert à transporter, jamais à protéger.

Hacher : à sens unique

Une fonction de hachage transforme une entrée de taille quelconque en une empreinte de taille fixe, de façon déterministe (même entrée → même empreinte) mais irréversible : impossible de retrouver l’entrée à partir de l’empreinte (autrement que par force brute). Une bonne fonction de hachage est aussi résistante aux collisions (dur de trouver deux entrées de même empreinte).

// Un hash SHA-256 : deterministe, a sens unique
// "bonjour" -> "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"
// On ne "dechiffre" pas ce hash : il n'y a rien a dechiffrer.

Deux usages distincts du hachage, à ne pas mélanger :

• Intégrité / empreinte : vérifier qu’un fichier n’a pas changé, comparer des contenus, indexer. Ici, un hash rapide (SHA-256) convient.
• Stockage de mots de passe : là, il faut au contraire un hachage lent et salé (argon2id, bcrypt) — c’est tout l’objet du chapitre 3.3. Un SHA-256 « nu » est inadapté aux mots de passe (trop rapide → bruteforçable).

💡 Réflexe — « On ne déchiffre pas un hash. » Si tu t’entends dire « je vais déchiffrer le mot de passe pour le comparer », stop : on ne déchiffre pas, on re-hache la valeur fournie et on compare les empreintes. Si tu as besoin de récupérer la valeur d’origine, c’est que tu voulais chiffrer, pas hacher.

Chiffrer : réversible avec une clé

Le chiffrement rend une donnée illisible (le chiffré) tout en permettant de la récupérer avec la bonne clé. C’est l’outil quand tu dois relire la donnée plus tard : chiffrer un champ sensible en base, protéger un fichier, sécuriser un transport (TLS).

clair  --chiffrer(clé)-->  chiffré  --déchiffrer(clé)-->  clair

Deux grandes familles (détaillées au chapitre 3.2) : symétrique (même clé pour chiffrer et déchiffrer, ex. AES-GCM) et asymétrique (clé publique / clé privée, ex. RSA). Le point de vigilance du dev : la sécurité repose entièrement sur la gestion de la clé (la garder secrète, la stocker hors du code — voir Partie 13). Un chiffrement AES parfait avec la clé dans le dépôt Git ne protège rien.

Le tableau des erreurs classiques

🎯 Côté attaquant — Face à une donnée « protégée », un attaquant identifie d’abord de quel type de protection il s’agit. Du Base64 ? Décodé en une seconde. Un hash rapide (MD5/SHA) sans sel ? Il le passe dans une base de hashes précalculés (rainbow tables) ou un GPU. Un chiffrement, mais la clé traîne dans le code/les logs/une variable exposée ? Il prend la clé. Les erreurs « encoder pour cacher », « hacher vite un mot de passe » et « chiffrer sans protéger la clé » sont précisément ce qu’il cherche.

🧭 Sur FormaCampus — FormaCampus applique le bon outil à chaque besoin : les mots de passe sont hachés en argon2id (jamais chiffrés, jamais un simple SHA) ; un éventuel numéro sensible à relire (ex. un identifiant externe qu’il faut réutiliser en clair) est chiffré en AES-GCM avec une clé stockée dans le vault (pas dans le code) ; les identifiants de session sont aléatoires (CSPRNG) puis simplement transportés. Et personne, jamais, ne considère un Base64 comme une protection.

✏️ Exercices

Exercice 1 — Quel outil ? Pour chaque besoin, dis s’il faut encoder, hacher ou chiffrer : (a) stocker les mots de passe des utilisateurs ; (b) mettre des octets binaires dans une URL ; (c) stocker un numéro de compte qu’on devra réafficher en clair à l’utilisateur ; (d) vérifier qu’un fichier téléchargé n’a pas été altéré.

Exercice 2 — Démonte l’affirmation. Un dev dit : « J’ai sécurisé le token en le passant en Base64 avant de l’envoyer au client. » Explique l’erreur et propose le bon raisonnement.

🧠 Quiz de révision

Chapitre suivant : Symétrique, asymétrique, TLS — une clé ou deux, et comment le web combine les deux pour établir une connexion sûre.