"Base64, JWT et Hachage : Ce Que C'est Vraiment (Sans Diplôme en Informatique)"

L'Écart Entre Utiliser Quelque Chose et le Comprendre

En début de carrière, je déboguais un problème d'authentification quand un développeur senior a demandé : « Le JWT est-il expiré ? »

J'ai dit oui, que j'avais vérifié. Ce que je n'ai pas avoué : j'avais collé le token sur un site web, vu le timestamp d'expiration, et ne comprenais toujours pas vraiment ce que je regardais. C'était sécurisé ? N'importe qui pouvait lire ce token ? Était-il chiffré ? Pourquoi n'importe quel site web pouvait-il le décoder s'il était soi-disant « signé » et « sécurisé » ?

Ce guide s'adresse à cette version de moi. Trois concepts qui apparaissent constamment dans le développement web, que la plupart des tutoriels supposent acquis, et qui sont en réalité simples une fois qu'on les explique clairement.

Base64 : Pas du Chiffrement. Pas de la Compression. Juste de la Traduction.

La chose la plus importante à savoir d'abord : le Base64 n'est pas un mécanisme de sécurité. Il ne cache pas vos données. N'importe qui peut le décoder instantanément. Si vous avez déjà pensé « ça a l'air encodé donc c'est probablement sûr de mettre ça dans une URL » — ce ne l'est pas.

Le Base64 est une façon de représenter des données binaires en utilisant uniquement des caractères ASCII imprimables. C'est tout. La raison pratique de son existence : les données binaires cassent les choses. Les emails, les en-têtes HTTP, les URLs, les attributs HTML — ces systèmes ont été conçus pour le texte. Les données binaires brutes, avec leurs octets nuls et leurs caractères de contrôle, peuvent se corrompre ou être altérées lors du transit par des systèmes texte.

Le Base64 convertit le binaire en un alphabet de 64 caractères sûrs : A–Z, a–z, 0–9, + et /. La sortie est environ 33 % plus grande que l'entrée, mais garantie de voyager intacte à travers n'importe quel système texte.

Où vous le verrez vraiment

Authentification HTTP Basic : quand vous vous authentifiez avec identifiant:motdepasse, les credentials sont encodés en Base64 et envoyés dans l'en-tête Authorization: Basic. C'est pourquoi Basic Auth sur HTTP simple est dangereux — quiconque intercepte la requête peut décoder les credentials immédiatement. HTTPS est obligatoire.

Tokens JWT : chacune des trois sections d'un token JWT est encodée en Base64url (une variante qui remplace + et / par - et _ pour être sûre dans les URLs).

Data URIs : <img src="data:image/png;base64,iVBORw0KGgo..."> — intégrer des données d'image directement dans le HTML ou le CSS au lieu de faire une requête HTTP séparée.

Pièces jointes email : l'encodage MIME utilise le Base64 pour que les fichiers binaires puissent voyager à travers des serveurs mail conçus uniquement pour le texte.

Essayez vous-même : collez n'importe quel texte dans l'Encodeur Base64 et regardez le résultat. Puis recollez la chaîne encodée pour la décoder. Remarquez que la version « encodée » ne dissimule rien — elle utilise simplement un alphabet différent.

JWT : Trois Chaînes Base64 et une Signature

Un JSON Web Token ressemble à ceci :

Exactement deux points. Trois sections.

En-tête — la partie avant le premier point. Se décode en métadonnées sur le token : quel algorithme de signature a été utilisé, quel type de token c'est.

Payload — la section du milieu. Se décode en claims réels : ID utilisateur, email, rôles, date d'expiration. C'est ce que votre backend lit pour identifier l'utilisateur.

Signature — la partie après le second point. Une preuve cryptographique que le token n'a pas été falsifié.

Ce Qui Surprend la Plupart des Développeurs

Le payload est encodé en Base64url. Il n'est pas chiffré. Quiconque possède le token peut décoder le payload et lire son contenu — ID utilisateur, email, rôles, expiration, tout ce que vous y avez mis.

Collez n'importe quel JWT dans le Décodeur JWT et voyez exactement ce qu'il contient. Aucune clé requise.

Ça surprend les gens parce que la chaîne ressemble à du charabia opaque. Elle ne l'est pas. Le modèle de sécurité du JWT est : « Je peux vérifier que ce token a été genuinement émis par mon serveur (vérification de signature), donc je peux faire confiance aux claims qu'il contient. Mais ces claims eux-mêmes ne sont pas secrets. »

L'implication pratique : ne mettez pas de mots de passe, de données de paiement ou d'informations personnelles sensibles dans les payloads JWT. Mettez uniquement ce qui est nécessaire pour identifier et autoriser l'utilisateur. L'ID utilisateur, le niveau d'abonnement et les rôles sont parfaitement acceptables.

Ce Que la Signature Garantit Vraiment

La signature est créée en prenant l'en-tête + le payload + une clé secrète que seul votre serveur connaît, et en les faisant passer par une fonction de hachage. Quand votre serveur reçoit un token, il recalcule la signature avec le même secret. Si la signature recalculée correspond à celle du token, le token est authentique et non modifié.

Si quelqu'un modifie le payload pour changer l'ID utilisateur 123 en 456 (pour usurper l'identité d'un autre utilisateur), la vérification de signature échoue — le payload modifié produit une signature différente de celle dans le token.

C'est pourquoi votre clé de signature JWT doit rester genuinement secrète. Si un attaquant la récupère, il peut forger des tokens et se faire passer pour n'importe quel utilisateur.

Hachage : Des Fonctions à Sens Unique

Une fonction de hachage prend n'importe quelle entrée et produit une sortie de taille fixe. Deux propriétés la rendent utile pour la sécurité :

Déterministe : la même entrée produit toujours la même sortie.

À sens unique : vous ne pouvez pas inverser le hash pour retrouver l'entrée originale. Il n'existe pas de fonction dehacher().

Un caractère de différence. Hash complètement différent. Aucune relation mathématique entre des entrées similaires et des sorties similaires.

Pourquoi les Mots de Passe Sont Hachés et Non Chiffrés

Si les mots de passe étaient chiffrés, on pourrait les déchiffrer avec la bonne clé. Si un attaquant vole votre base de données et votre clé de chiffrement, chaque mot de passe utilisateur est exposé.

Avec le hachage : vous stockez le hash, pas le mot de passe. Quand un utilisateur se connecte, vous hachez ce qu'il a tapé et comparez au hash stocké. S'ils correspondent, le mot de passe est correct. Vous n'avez jamais besoin de récupérer l'original — vous avez juste besoin de vérifier une tentative.

Même si un attaquant obtient votre base de données, il n'a que des hashs. Pour obtenir un mot de passe, il doit deviner et vérifier, ce qui est beaucoup plus lent que de simplement lire.

MD5, SHA-256, bcrypt — Pourquoi le Choix Compte

MD5 était la norme au début des années 2000. Il est maintenant considéré comme cassé pour la sécurité. Un GPU moderne peut calculer des milliards de hashs MD5 par seconde, ce qui signifie qu'un attaquant avec votre base de données peut cracker des mots de passe simples en quelques minutes par force brute. N'utilisez jamais MD5 pour des mots de passe.

SHA-256 convient à la vérification d'intégrité — confirmer qu'un fichier n'a pas été corrompu ou altéré, générer des signatures HMAC pour des webhooks API. Mais il est trop rapide pour les mots de passe. Un hachage rapide est mauvais pour les mots de passe car il rend les attaques par force brute bon marché.

bcrypt est spécifiquement conçu pour les mots de passe. Il est intentionnellement lent — vous pouvez régler combien de tours de calcul il effectue — et inclut un « sel » intégré (données aléatoires) qui garantit que deux mots de passe identiques produisent des hashs complètement différents. Cela neutralise les attaques par table arc-en-ciel (bases de données de hashs précalculés).

La règle : utilisez bcrypt (ou Argon2, ou scrypt) pour les mots de passe. Utilisez SHA-256 pour tout le reste nécessitant une vérification d'intégrité.

Expérimentez avec le Générateur de Hash — tapez « motdepasse » dans MD5, SHA-256 et SHA-512 et comparez les longueurs de sortie. Puis changez un caractère et observez combien le hash change complètement.

Référence Rapide

Comprendre ces trois concepts correctement évite une catégorie d'erreurs de sécurité qui paraissent correctes à la revue de code et ne remontent qu'en production — au moment où les dégâts sont déjà faits.

Les outils : Base64, Décodeur JWT, Générateur de Hash. Utilisez-les pour tester votre compréhension, pas seulement pour obtenir des résultats.