Défaillances cryptographiques (A04) : hacher, chiffrer, HTTPS

Les défaillances cryptographiques (Cryptographic Failures, A04:2025) regroupent les données sensibles mal protégées : transmises sans chiffrement, stockées en clair ou avec un algorithme trop faible, protégées par des clés mal gardées ou un aléatoire prévisible. Ce chapitre explique la différence entre hachage et chiffrement, comment stocker un mot de passe, comment chiffrer une donnée qu'on doit relire, à quoi sert TLS et quelles erreurs éviter.

Identifier les données à protéger

Avant de choisir un algorithme, on classe les données. Dans AppliFrais :

Les données sont à protéger à deux moments : en transit, quand elles circulent sur le réseau (TLS), et au repos, quand elles sont stockées en base, sur disque ou dans une sauvegarde (hachage, chiffrement).

Hachage ou chiffrement : la différence

Une fonction de hachage transforme une entrée de taille quelconque en une empreinte de taille fixe. Elle est déterministe (la même entrée donne toujours la même empreinte), à sens unique, et la moindre modification de l'entrée change toute l'empreinte :

SHA-256("azerty") = f2d81a260dea8a100dd517984e53c56a7523d96942a834b9cdc249bd4e8c7aa9
SHA-256("azertz") = 7dd6e0b180a8a39b2480194fd498092b474415346da395c3cd12b9ca1b8a5a8c

Stocker un mot de passe

On ne stocke jamais un mot de passe, ni en clair, ni chiffré : avec la clé, un attaquant ou un administrateur indélicat déchiffrerait tout. On stocke son empreinte. À la connexion, on calcule l'empreinte du mot de passe saisi et on la compare à celle de la base.

Mais une simple empreinte SHA-256 ne suffit pas, pour deux raisons.

Les attaques par dictionnaire et par tables précalculées. Les mêmes mots de passe donnent les mêmes empreintes. Un attaquant qui vole la base compare les empreintes à des listes d'empreintes de mots de passe courants (rainbow tables) : f2d81a26… est reconnu immédiatement comme azerty. La parade est le sel : une valeur aléatoire, différente pour chaque compte, ajoutée au mot de passe avant le hachage et stockée à côté de l'empreinte. Deux utilisateurs qui ont choisi azerty ont alors des empreintes différentes, et les tables précalculées ne servent plus à rien.

La vitesse. SHA-256 et MD5 sont conçus pour être rapides. Une seule carte graphique calcule des milliards d'empreintes MD5 par seconde : essayer toutes les combinaisons d'un mot de passe court devient trivial. Pour les mots de passe, on veut au contraire une fonction volontairement lente et gourmande en mémoire, dont on règle le coût.

Les ordres de grandeur suivants montrent l'effet de la lenteur. Ils supposent un attaquant qui teste toutes les combinaisons d'un mot de passe de 8 caractères parmi les 62 lettres et chiffres, soit 62⁸ ≈ 2,18 × 10¹⁴ possibilités :

Les vitesses réelles dépendent du matériel ; l'écart, lui, reste de plusieurs ordres de grandeur.

Les algorithmes recommandés par l'OWASP pour les mots de passe :

Ces fonctions génèrent le sel elles-mêmes et l'intègrent à l'empreinte, avec l'algorithme et le coût. Tu n'as rien à gérer à la main. En PHP :

// Inscription : PASSWORD_DEFAULT utilise bcrypt, avec un coût de 12 depuis PHP 8.4
$hash = password_hash($motDePasse, PASSWORD_DEFAULT);
// ou, si PHP a été compilé avec Argon2 :
$hash = password_hash($motDePasse, PASSWORD_ARGON2ID);
// $hash ressemble à : $2y$12$… (algorithme, coût, sel et empreinte dans une seule chaîne)

// Connexion
if (password_verify($saisie, $hashEnBase)) {
    if (password_needs_rehash($hashEnBase, PASSWORD_DEFAULT)) {
        // l'algorithme ou le coût par défaut a changé : on met l'empreinte à jour
        $nouveau = password_hash($saisie, PASSWORD_DEFAULT);
        // UPDATE utilisateur SET mdp_hash = ? WHERE id = ?
    }
    // connexion réussie
}

En Node.js, avec le paquet argon2 :

import argon2 from 'argon2';

const hash = await argon2.hash(motDePasse);            // Argon2id par défaut, sel aléatoire inclus
const valide = await argon2.verify(hashEnBase, saisie); // true ou false

La colonne mdp_hash doit être assez longue : 255 caractères (VARCHAR(255)) laissent de la marge pour un changement d'algorithme.

Chiffrer une donnée qu'on doit relire

Le RIB doit être relu pour payer : on le chiffre. Le chiffrement symétrique utilise la même clé pour chiffrer et déchiffrer ; c'est le bon choix pour des données stockées. L'algorithme de référence est AES, avec une clé de 256 bits et le mode GCM, qui chiffre et garantit en plus l'intégrité : toute modification du texte chiffré est détectée au déchiffrement.

import crypto from 'node:crypto';

// Clé de 32 octets (256 bits), lue depuis un secret, jamais écrite dans le code
const cle = Buffer.from(process.env.CLE_RIB, 'hex');

export function chiffrer(texte) {
  const iv = crypto.randomBytes(12);                       // vecteur d'initialisation, unique à chaque fois
  const chiffreur = crypto.createCipheriv('aes-256-gcm', cle, iv);
  const chiffre = Buffer.concat([chiffreur.update(texte, 'utf8'), chiffreur.final()]);
  const tag = chiffreur.getAuthTag();                      // 16 octets qui garantissent l'intégrité
  return Buffer.concat([iv, tag, chiffre]).toString('base64');
}

export function dechiffrer(donnee) {
  const brut = Buffer.from(donnee, 'base64');
  const iv = brut.subarray(0, 12), tag = brut.subarray(12, 28), chiffre = brut.subarray(28);
  const dechiffreur = crypto.createDecipheriv('aes-256-gcm', cle, iv);
  dechiffreur.setAuthTag(tag);                             // lève une erreur si la donnée a été modifiée
  return Buffer.concat([dechiffreur.update(chiffre), dechiffreur.final()]).toString('utf8');
}

Trois règles :

1. Le vecteur d'initialisation (IV) est unique pour chaque chiffrement avec la même clé. Il n'est pas secret : on le stocke avec la donnée chiffrée. Réutiliser un IV avec AES-GCM détruit la sécurité.
2. La clé ne se stocke pas à côté des données. Une clé dans la même base que les RIB chiffrés ne protège de rien si la base est volée. Elle va dans un coffre-fort de secrets ou un service de gestion de clés (KMS), et l'accès y est limité.
3. On n'invente pas sa cryptographie. On utilise les fonctions éprouvées du langage (crypto de Node.js, sodium_crypto_secretbox ou openssl_encrypt en PHP) et des modes reconnus.

Les SGBD proposent aussi du chiffrement : chiffrement de colonnes, chiffrement transparent des fichiers de la base (TDE), chiffrement des sauvegardes. Le chapitre Injection SQL et protection des données du cours SQL montre AES_ENCRYPT sous MySQL et le chiffrement sous SQL Server, sujet d'annales de l'E7.

Chiffrement asymétrique et signature

Le chiffrement asymétrique utilise une paire de clés : une clé publique, que tout le monde peut connaître, et une clé privée, que seul son propriétaire détient. Ce qui est chiffré avec la clé publique ne se déchiffre qu'avec la clé privée. Il est lent, et sert surtout à deux choses :

• établir une clé symétrique commune au début d'une connexion TLS (échange Diffie-Hellman, la clé privée du certificat servant à le signer pour prouver l'identité du serveur) ;
• signer : le propriétaire calcule une signature avec sa clé privée ; tout le monde la vérifie avec la clé publique. La signature prouve l'origine et l'intégrité d'un document, d'une mise à jour ou d'un jeton JWT signé en RS256 ou ES256.

Les algorithmes courants : RSA (clés de 3 072 bits ou plus pour un usage durable), et les courbes elliptiques (ECDSA, Ed25519), plus rapides à sécurité égale. Les certificats, les autorités de certification et la PKI sont traités dans le cours Cybersécurité des infrastructures.

HTTPS et TLS : protéger les échanges

HTTPS est HTTP transporté dans une connexion chiffrée par TLS. TLS garantit trois choses : la confidentialité (personne sur le réseau ne lit le mot de passe ou le jeton), l'intégrité (personne ne modifie la page en route) et l'authentification du serveur (le certificat prouve que tu parles bien à frais.gsb.fr, et pas à un imposteur sur le Wi-Fi public).

Les règles actuelles :

• HTTPS partout, pas seulement sur la page de connexion : un cookie de session envoyé une seule fois en HTTP peut être volé.
• TLS 1.2 au minimum, TLS 1.3 de préférence. TLS 1.0 et 1.1 sont officiellement obsolètes depuis 2021 (RFC 8996), SSL depuis bien plus longtemps.
• Un certificat valide, délivré par une autorité reconnue. Let's Encrypt en délivre gratuitement, renouvelés automatiquement. La durée de validité maximale des certificats diminue progressivement : 200 jours depuis mars 2026, et 47 jours prévus en 2029. Le renouvellement doit donc être automatisé.
• Redirection de HTTP vers HTTPS et en-tête HSTS, qui interdit au navigateur de revenir en HTTP (chapitre 9).
• Les connexions internes aussi : entre l'API et la base, entre l'application et un service de mail, quand elles traversent un réseau partagé.

La mise en place d'un certificat sur un hébergement est expliquée dans le cours HTML et CSS.

Générer de l'aléatoire sûr

Les jetons de session, les jetons de réinitialisation de mot de passe, les sels, les IV et les clés doivent être imprévisibles. Les générateurs ordinaires ne le sont pas : Math.random() en JavaScript, rand() et mt_rand() en PHP, java.util.Random produisent des suites qu'un attaquant peut prédire à partir de quelques valeurs.

$jeton = bin2hex(random_bytes(32));   // 64 caractères hexadécimaux, 256 bits d'aléa

Les erreurs cryptographiques classiques

Ce chapitre résume ce que la sécurité applicative attend de la cryptographie. Pour le fonctionnement interne des algorithmes et des certificats, appuie-toi sur le cours Cybersécurité des infrastructures.

const hash = crypto.createHash('md5').update(req.body.mdp).digest('hex');
await db.execute('INSERT INTO utilisateur (login, mdp_hash) VALUES (?, ?)', [req.body.login, hash]);

const hash = await argon2.hash(req.body.mdp);
await db.execute('INSERT INTO utilisateur (login, mdp_hash) VALUES (?, ?)', [req.body.login, hash]);

Pour aller plus loin. Le cours Cryptographie reprend chaque outil en profondeur : chiffrement symétrique, fonction de hachage, stockage des mots de passe et TLS 1.3.