Stocker un mot de passe : sel, bcrypt et Argon2

Stocker un mot de passe correctement, c'est ne jamais le stocker : on enregistre à la place une empreinte calculée par une fonction de hachage spécialisée, volontairement lente, avec un sel aléatoire propre à chaque compte, comme bcrypt ou Argon2id. À la connexion, on recalcule l'empreinte du mot de passe saisi et on la compare. Ce chapitre explique pourquoi ni le stockage en clair, ni le chiffrement, ni un SHA-256 ne conviennent, comment fonctionnent le sel et le facteur de coût, comment coder tout cela en PHP, Node.js et C#, et ce que recommandent la CNIL et l'ANSSI.

C'est la question de cryptographie la plus fréquente des sujets d'E7 SLAM : elle est tombée en 2022, en 2025 et en 2026.

Pourquoi ni en clair, ni chiffré

En clair, un mot de passe est exposé à quiconque lit la base : un administrateur, un prestataire, un attaquant qui a réussi une injection SQL, le voleur d'une sauvegarde. Et le dommage déborde ton application : la plupart des gens réutilisent leurs mots de passe, et l'attaquant essaiera le couple adresse et mot de passe sur leur messagerie, leur banque, leurs autres comptes professionnels.

Chiffré, le mot de passe est réversible : qui détient la clé peut tous les déchiffrer. Or la clé doit être accessible à l'application pour vérifier les connexions, donc sur le même serveur : un attaquant qui compromet le serveur récupère la base et la clé. Et l'on n'a jamais besoin de relire un mot de passe : il suffit de vérifier qu'un mot de passe saisi est le bon.

Une exception confirme la règle : le mot de passe qu'une application doit elle-même présenter à un autre système (le compte de service avec lequel elle se connecte à une base, à un annuaire, à une API). Celui-là doit pouvoir être relu, donc il se chiffre, avec une clé gardée hors de la base, ou mieux, il se range dans un coffre de secrets. Le sujet SLAM 2023 (cas Lama) en donne un exemple dans son dossier documentaire : le mot de passe d'un rôle applicatif y est « chiffré de façon réversible » parce que « le pilote de connexion à la base métier nécessite le mot de passe en clair ». Hacher sert à vérifier un secret qu'on reçoit ; chiffrer sert à garder un secret qu'on devra envoyer.

Corollaire : une application bien conçue ne peut pas renvoyer son mot de passe à un utilisateur qui l'a oublié. Si un site t'envoie ton ancien mot de passe par courriel, il le stocke en clair ou chiffré. La bonne procédure : un lien de réinitialisation à usage unique, contenant un jeton aléatoire, valable peu de temps, qui permet de choisir un nouveau mot de passe.

Pourquoi un hachage rapide ne suffit pas

SHA-256 est irréversible ; pourquoi ne pas l'utiliser ? Parce qu'il est conçu pour être rapide. L'attaquant qui vole la base ne cherche pas à inverser la fonction : il devine. Il hache des milliards de mots de passe candidats et compare les empreintes à celles de la base. C'est l'attaque hors ligne, sans aucune limite de tentatives, puisque ton application n'est plus dans la boucle.

Une carte graphique haut de gamme calcule de l'ordre de 20 milliards d'empreintes SHA-256 par seconde (bancs d'essai publics de l'outil hashcat). Prenons la politique du sujet E7 SLAM 2025 (cas Casterman) : des mots de passe de 6 caractères, choisis librement. Même s'ils mélangeaient majuscules, minuscules et chiffres (62 symboles), il y aurait 62⁶ ≈ 5,7 × 10¹⁰ combinaisons, toutes essayées en moins de 3 secondes. Et l'attaquant commence par les listes de mots de passe issus de fuites précédentes, des centaines de millions de vrais mots de passe, qui contiennent presque tous les choix humains.

D'où le cahier des charges d'une fonction de hachage de mots de passe :

• lente, réglable par un facteur de coût : quelques dizaines de millisecondes pour toi à chaque connexion, mais des milliers de fois moins d'essais par seconde pour l'attaquant ;
• gourmande en mémoire si possible, pour neutraliser les cartes graphiques et les circuits spécialisés, qui ont beaucoup de cœurs mais peu de mémoire par cœur ;
• salée.

Avec bcrypt de coût 12, la même carte graphique ne calcule plus que de l'ordre de 1 400 empreintes par seconde : essayer les 62⁶ combinaisons prendrait plus d'un an, au lieu de 3 secondes.

Le sel : un aléa différent pour chaque compte

Sans sel, deux utilisateurs qui ont le même mot de passe ont la même empreinte. L'attaquant le voit immédiatement, et il peut utiliser des tables précalculées (dont les tables arc-en-ciel) : des milliards de couples « mot de passe, empreinte » calculés une fois pour toutes et réutilisés contre chaque base volée.

Le sel est une valeur aléatoire, différente pour chaque compte, ajoutée au mot de passe avant le hachage et stockée en clair à côté de l'empreinte. Il n'est pas secret ; il rend chaque empreinte unique.

Le sel apporte trois choses :

1. deux mots de passe identiques donnent des empreintes différentes : l'attaquant ne repère plus les doublons ;
2. les tables précalculées deviennent inutiles : il faudrait en calculer une par valeur de sel ;
3. l'attaquant doit attaquer chaque compte séparément : le coût de l'attaque est multiplié par le nombre de comptes.

La CNIL recommande un sel « généré aléatoirement » d'une « longueur minimale de 128 bits », « généré pour chaque utilisateur et stocké dans la même base de données que les mots de passe ». Les fonctions modernes (bcrypt, Argon2id) génèrent le sel elles-mêmes et l'enregistrent dans la chaîne produite : tu n'as rien à gérer.

Le poivre (pepper) est un complément facultatif : une valeur secrète, la même pour tous les comptes, ajoutée au calcul (souvent sous forme d'un HMAC) mais stockée hors de la base, dans la configuration du serveur ou un coffre de secrets. Un attaquant qui ne vole que la base, par une injection SQL ou une sauvegarde, ne peut alors rien tester sans le poivre.

bcrypt, Argon2id, scrypt, PBKDF2 : les fonctions de hachage de mots de passe

Les deux variantes d'Argon2 qu'on croise dans les sujets : Argon2i, conçue pour résister aux attaques par canaux auxiliaires, et Argon2id, un mélange d'Argon2i et d'Argon2d, recommandé par la RFC 9106 et par l'OWASP pour les mots de passe. Si un sujet demande Argon2i, utilise-le ; si tu choisis, prends Argon2id.

Ces fonctions produisent une chaîne qui contient tout ce qu'il faut pour vérifier : l'algorithme, les paramètres, le sel et l'empreinte. Une colonne VARCHAR(255) suffit.

$2y$12$9fNnOE0tqW1JX1ZPz2Uyp.Wn7hY1u7s6m5h3k0y8bQq1K1o2cW3a2
 │   │  └ sel (22 caractères) puis empreinte (31 caractères)
 │   └ coût : 2¹² itérations
 └ algorithme : bcrypt

$argon2id$v=19$m=65536,t=4,p=1$eziCjheI5regP4il9EX1HQ$Rq1m…
 │          │    │                └ sel en Base64       └ empreinte
 │          │    └ 64 Mio de mémoire, 4 passes, 1 fil d'exécution
 │          └ version de l'algorithme
 └ algorithme : Argon2id

En PHP : password_hash, password_verify, password_needs_rehash

PHP fournit tout depuis la version 5.5. Trois fonctions suffisent, et elles gèrent le sel toutes seules :

<?php
// Inscription : calculer l'empreinte (colonne mot_de_passe VARCHAR(255))
$hache = password_hash($motDePasse, PASSWORD_ARGON2ID);   // ou PASSWORD_DEFAULT (bcrypt)
$stmt = $pdo->prepare('INSERT INTO client (email, mot_de_passe) VALUES (?, ?)');
$stmt->execute([$email, $hache]);

// Connexion : vérifier
$stmt = $pdo->prepare('SELECT id, mot_de_passe FROM client WHERE email = ?');
$stmt->execute([$email]);
$client = $stmt->fetch();
if ($client !== false && password_verify($motDePasse, $client['mot_de_passe'])) {
    session_regenerate_id(true);
    $_SESSION['client_id'] = $client['id'];
} else {
    // Message identique que l'adresse existe ou non : ne pas aider l'attaquant
    $erreur = 'Adresse ou mot de passe incorrect.';
}

password_verify() lit l'algorithme, le coût et le sel dans la chaîne stockée, recalcule l'empreinte du mot de passe saisi et compare les deux en temps constant. Ne compare jamais deux empreintes avec == et ne recalcule jamais toi-même l'empreinte pour la passer dans le WHERE d'une requête : avec un sel aléatoire, elle serait différente à chaque calcul.

Migrer depuis un vieux SHA-1. C'est la situation du sujet E7 SLAM 2026 (cas NDV) : la base contient des empreintes SHA1($motDePasse) et il faut passer à Argon2. On ne peut pas convertir les empreintes existantes, puisqu'on ne connaît pas les mots de passe. On les migre à la connexion, au moment où l'utilisateur saisit son mot de passe :

<?php
$hache = $client['mot_de_passe'];
$ancienFormat = !str_starts_with($hache, '$');           // 40 caractères hexadécimaux : SHA-1
$valide = $ancienFormat
    ? hash_equals($hache, sha1($motDePasse))             // comparaison en temps constant
    : password_verify($motDePasse, $hache);

if ($valide && ($ancienFormat || password_needs_rehash($hache, PASSWORD_ARGON2ID))) {
    $nouveau = password_hash($motDePasse, PASSWORD_ARGON2ID);
    $maj = $pdo->prepare('UPDATE client SET mot_de_passe = ? WHERE id = ?');
    $maj->execute([$nouveau, $client['id']]);
}

password_needs_rehash() sert aussi plus tard : quand tu augmentes le coût ou changes d'algorithme, chaque empreinte est recalculée à la connexion suivante. Pour les comptes qui ne se reconnectent jamais, on peut envelopper l'ancienne empreinte (password_hash(sha1_existant, PASSWORD_ARGON2ID)) en marquant le compte, ou forcer une réinitialisation par courriel au bout d'un délai.

En Node.js et en C#

En Node.js, le paquet npm argon2 (ou bcrypt) joue le rôle de password_hash :

import argon2 from 'argon2';

const hache = await argon2.hash(motDePasse);          // Argon2id par défaut, sel inclus
if (await argon2.verify(hache, motDePasse)) {
  // connexion acceptée
}

En C#, le paquet NuGet BCrypt.Net-Next est le plus utilisé, et ASP.NET Core Identity fournit son propre PasswordHasher, fondé sur PBKDF2 :

string hache = BCrypt.Net.BCrypt.HashPassword(motDePasse, workFactor: 12);
bool valide = BCrypt.Net.BCrypt.Verify(motDePasse, hache);

Quel que soit le langage, la règle est la même : une fonction de la bibliothèque standard ou d'une bibliothèque reconnue, jamais un assemblage maison du genre sha256(sel + motDePasse).

La politique de mots de passe : ce que recommandent la CNIL et l'ANSSI

Hacher correctement ne sert à rien si les utilisateurs choisissent 123456. La CNIL a fixé ses attentes dans une recommandation de 2022 (délibération n° 2022-100 du 21 juillet 2022), alignée sur le guide de l'ANSSI « Recommandations relatives à l'authentification multifacteur et aux mots de passe ». Elle raisonne en entropie, mesurée en bits : un mot de passe de L caractères tirés au hasard parmi N symboles a une entropie de L × log₂(N) bits.

Vérifions le premier exemple : 26 majuscules + 26 minuscules + 10 chiffres + 37 caractères spéciaux = 99 symboles ; 12 × log₂(99) ≈ 12 × 6,63 ≈ 79,6 bits, soit environ 80. Le deuxième : 14 × log₂(62) ≈ 14 × 5,95 ≈ 83,4 bits.

D'autres points de la recommandation tombent souvent :

• les responsables de traitement « ne devraient plus imposer de modification périodique des mots de passe » à tous les utilisateurs ; un renouvellement périodique reste nécessaire pour les comptes à privilèges ;
• un mot de passe doit être changé dès qu'il est compromis, et l'utilisateur prévenu en cas de fuite ;
• les mots de passe couramment utilisés doivent être refusés, en informant l'utilisateur ;
• le mot de passe ne doit jamais être transmis en clair, ni affiché, ni envoyé par courriel.

La meilleure protection reste de ne pas dépendre du seul mot de passe : l'authentification multifacteur (code à usage unique, clé de sécurité FIDO2, ou passkey, une paire de clés stockée sur l'appareil qui remplace le mot de passe). Le cours sur l'authentification et les habilitations développera ces mécanismes.

À l'E7 : comment la notion est demandée

Le document fourni avec le sujet 2026 présente SHA-256 comme « robuste et largement utilisé pour le stockage sécurisé des mots de passe ». Ce n'est vrai qu'avec un sel et un très grand nombre d'itérations (c'est-à-dire PBKDF2) : un SHA-256 simple est bien trop rapide. Le même document, lui, recommande sans ambiguïté bcrypt et Argon2i, conçus pour cet usage.

En SISR, la même logique s'applique aux comptes des équipements et des annuaires : les mots de passe des comptes locaux d'un commutateur se stockent avec un algorithme fort (sur les équipements Cisco, le type 8 ou 9 plutôt que le type 7, simplement réversible), et la politique de mots de passe de l'annuaire Active Directory se règle par stratégie de groupe.

Pour aller plus loin. Longueur, complexité, verrouillage et réinitialisation sont traités dans le chapitre Politique de mots de passe du cours Authentification.

Exercices

$hache = sha1($_POST['password']);
$req = $pdo->prepare('INSERT INTO compte (login, password) VALUES (:login, :password)');
$req->bindParam(':login', $_POST['login']);
$req->bindParam(':password', $hache);
$req->execute();