Authentification (A07) : mots de passe, sessions, JWT et MFA

Les défaillances d'authentification (Authentication Failures, A07:2025) regroupent tout ce qui permet à un attaquant de se faire passer pour un autre utilisateur : mots de passe faibles acceptés, essais illimités, session mal gérée, jeton mal vérifié, récupération de compte fragile. Ce chapitre présente les attaques contre l'authentification et leurs parades : politique de mots de passe, limitation des tentatives, sessions côté serveur, jetons JWT, double authentification, réinitialisation de mot de passe et authentification unique (SSO).

Les attaques contre l'authentification

Une politique de mots de passe à jour

Les règles d'hier (huit caractères, une majuscule, un chiffre, changement tous les 90 jours) produisent des mots de passe comme Gsb2026!, puis Gsb2026!! trois mois plus tard. Les recommandations actuelles misent sur la longueur et sur le refus des mots de passe connus.

La CNIL, dans sa recommandation de 2022 sur les mots de passe, raisonne en entropie, c'est-à-dire en nombre de combinaisons possibles exprimé en bits. Pour un mot de passe utilisé seul, elle retient un minimum de 80 bits, ce qui correspond par exemple à 12 caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux. Quand l'accès est restreint par des mesures complémentaires (blocage temporaire après plusieurs échecs, captcha), un niveau de 50 bits peut suffire.

Pour vérifier qu'un mot de passe n'a pas fuité, le service Pwned Passwords de Have I Been Pwned permet une vérification sans transmettre le mot de passe : on envoie les cinq premiers caractères de son empreinte SHA-1, le service renvoie toutes les empreintes qui commencent ainsi, et la comparaison se fait localement.

Limiter les tentatives de connexion

Sans limite, un script essaie des milliers de mots de passe par minute. Plusieurs mécanismes se combinent :

• une limite par compte : après un nombre d'échecs (par exemple 10), un délai croissant ou un blocage temporaire ;
• une limite par adresse IP, contre le password spraying qui vise beaucoup de comptes depuis la même source ;
• un captcha après quelques échecs ;
• une alerte quand les échecs dépassent un seuil anormal (chapitre 12).

Avec Express, le middleware express-rate-limit limite le nombre de requêtes par client sur une fenêtre de temps :

import rateLimit from 'express-rate-limit';

const limiteConnexion = rateLimit({
  windowMs: 15 * 60 * 1000,   // fenêtre de 15 minutes
  limit: 10,                   // 10 tentatives par adresse IP et par fenêtre
  standardHeaders: 'draft-8',
  legacyHeaders: false,
  message: { erreur: 'Trop de tentatives, réessaie plus tard' },
});

app.post('/api/connexion', limiteConnexion, connexion);

Un blocage définitif après quelques échecs est une mauvaise idée : n'importe qui pourrait bloquer le compte du comptable la veille de la clôture, ce qui est un déni de service. On préfère un blocage temporaire qui s'allonge, et une alerte.

Contre l'énumération des comptes, la réponse est la même dans tous les cas d'échec, et elle prend le même temps :

const [lignes] = await pool.execute('SELECT id, role, mdp_hash FROM utilisateur WHERE login = ? AND actif = 1', [login]);
const utilisateur = lignes[0];
// Même si le compte n'existe pas, on fait une vérification : le temps de réponse ne trahit rien
const valide = await argon2.verify(utilisateur?.mdp_hash ?? HASH_FACTICE, mdp);
if (!utilisateur || !valide) {
  journaliser('connexion', login, req.ip, 'echec');
  return res.status(401).json({ erreur: 'Identifiant ou mot de passe incorrect' });
}

HASH_FACTICE est une empreinte Argon2id calculée une fois au démarrage, pour que la vérification dure autant qu'avec un vrai compte.

Les sessions côté serveur

Avec une session, le serveur garde l'état de la connexion (qui est connecté, avec quel rôle) dans un stockage qui lui appartient : fichiers, base de données, Redis. Le navigateur ne reçoit qu'un identifiant de session aléatoire, dans un cookie. C'est le fonctionnement par défaut de PHP ($_SESSION) et d'express-session.

Les règles :

1. Changer d'identifiant à la connexion. Sinon, un attaquant qui a imposé un identifiant à la victime avant qu'elle se connecte (fixation de session) se retrouve connecté avec elle.
2. Protéger le cookie : Secure, HttpOnly, SameSite (attributs des cookies).
3. Expirer : après une période d'inactivité (par exemple 30 minutes pour une application de gestion) et après une durée maximale absolue.
4. Détruire la session à la déconnexion, côté serveur, pas seulement le cookie.
5. Redemander le mot de passe avant une action sensible (changer d'adresse mail ou de mot de passe, consulter un RIB).

// Connexion réussie
session_regenerate_id(true);           // nouvel identifiant, l'ancien est supprimé
$_SESSION['id'] = $utilisateur['id'];
$_SESSION['role'] = $utilisateur['role'];
$_SESSION['derniere_activite'] = time();

// À chaque requête : expiration après 30 minutes d'inactivité
if (time() - ($_SESSION['derniere_activite'] ?? 0) > 1800) {
    session_unset();
    session_destroy();
    http_response_code(401);
    exit;
}
$_SESSION['derniere_activite'] = time();

// Déconnexion
$_SESSION = [];
session_destroy();

Avec express-session, req.session.regenerate() crée le nouvel identifiant après la vérification du mot de passe, et req.session.destroy() termine la session. Le cours PHP et MySQL détaille les sessions et les cookies en PHP et le circuit d'inscription et de connexion.

JWT : fonctionnement et pièges

Un JWT (JSON Web Token) est un jeton qui contient lui-même les informations sur l'utilisateur, signées par le serveur. Le serveur n'a rien à stocker : à chaque requête, il vérifie la signature et lit le contenu. C'est le mode d'authentification courant des API REST, et celui de la version Node.js d'AppliFrais.

Un JWT est formé de trois parties encodées en Base64URL et séparées par des points : l'en-tête (l'algorithme de signature), la charge utile (les informations, appelées claims) et la signature.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsInJvbGUiOiJ2aXNpdGV1ciIsImlhdCI6MTc3MzMwNjAwMCwiZXhwIjoxNzczMzA2OTAwfQ.HZsnhRiNap-wV-wtmQEkETW9XOyyfJVrDDdvQw9wIyg

Décodées, les deux premières parties donnent :

{ "alg": "HS256", "typ": "JWT" }
{ "sub": "42", "role": "visiteur", "iat": 1773306000, "exp": 1773306900 }

sub (subject) est l'identifiant de l'utilisateur, iat (issued at) la date d'émission et exp la date d'expiration, en secondes depuis le 1er janvier 1970 : ici, émis le 12 mars 2026 à 9 h 00 UTC, il expire 15 minutes plus tard. La signature est un HMAC-SHA256 des deux premières parties, calculé avec un secret que seul le serveur connaît.

Avec la bibliothèque jsonwebtoken :

import jwt from 'jsonwebtoken';

// À la connexion
const jeton = jwt.sign(
  { sub: String(utilisateur.id), role: utilisateur.role },
  process.env.JWT_SECRET,
  { algorithm: 'HS256', expiresIn: '15m' }
);

// Middleware de vérification
function authentifier(req, res, next) {
  const [type, jeton] = (req.get('Authorization') ?? '').split(' ');
  if (type !== 'Bearer' || !jeton) return res.status(401).json({ erreur: 'Authentification requise' });
  try {
    const charge = jwt.verify(jeton, process.env.JWT_SECRET, { algorithms: ['HS256'] });
    req.utilisateur = { id: Number(charge.sub), role: charge.role };
    next();
  } catch {
    return res.status(401).json({ erreur: 'Jeton invalide ou expiré' });   // échec : on refuse
  }
}

Les pièges classiques :

La révocation. Un JWT reste valide jusqu'à son expiration, même si l'utilisateur se déconnecte ou si son compte est désactivé : le serveur ne garde aucune trace des jetons émis. D'où le couple habituel : un jeton d'accès très court, et un jeton de rafraîchissement plus long, stocké côté serveur (donc révocable), envoyé dans un cookie HttpOnly; Secure; SameSite=Strict, qui sert seulement à obtenir un nouveau jeton d'accès. À chaque utilisation, le jeton de rafraîchissement est remplacé par un nouveau (rotation) ; la réutilisation d'un ancien trahit un vol et révoque toute la chaîne.

Le cours Node.js et Express montre la mise en place complète d'une authentification JWT, et le cours React où le front garde la session.

Session ou JWT : que choisir ?

Aucune solution n'est « plus sûre » dans l'absolu : la session est plus simple à bien faire pour une application web classique, le JWT s'impose quand plusieurs clients ou plusieurs services consomment la même API.

Double authentification : TOTP, clés d'accès, SMS

L'authentification multifacteur (MFA), ou à deux facteurs (2FA), combine au moins deux facteurs de natures différentes :

Deux mots de passe ne font pas une MFA : ce sont deux facteurs de la même nature.

Pour AppliFrais, la MFA est indispensable sur les comptes comptable et administrateur, qui déclenchent des paiements et gèrent les droits.

Réinitialiser un mot de passe sans faille

La fonction « mot de passe oublié » est une porte d'entrée vers chaque compte : elle doit être aussi solide que la connexion. Les mauvaises pratiques : renvoyer le mot de passe par mail (il est donc stocké en clair ou chiffré, ce qui est une faille en soi), envoyer un nouveau mot de passe en clair, utiliser une question secrète.

Le processus recommandé, attendu dans le sujet E7 SLAM 2025 (corrigé, dossier D) :

1. L'utilisateur saisit son adresse mail. La page répond toujours « Si un compte correspond, un mail a été envoyé », pour ne pas révéler quels comptes existent.
2. Le serveur génère un jeton aléatoire long (random_bytes(32)), en stocke l'empreinte en base avec une expiration courte (15 à 30 minutes) et l'état « non utilisé ».
3. Il envoie par mail un lien qui contient le jeton en clair : https://frais.gsb.fr/reinitialiser?jeton=….
4. Au clic, le serveur retrouve l'empreinte, vérifie qu'elle existe, n'a pas expiré et n'a pas servi. L'utilisateur choisit lui-même son nouveau mot de passe, qui est haché.
5. Le jeton est invalidé, les sessions ouvertes du compte sont fermées, et un mail confirme le changement (sans mot de passe), pour que le vrai titulaire réagisse s'il n'est pas à l'origine de la demande.
6. Les demandes sont limitées par compte et par adresse IP.

// Étape 2 : création du jeton
$jeton = bin2hex(random_bytes(32));
$stmt = $pdo->prepare('INSERT INTO reinit_mdp (id_utilisateur, jeton_hash, expire_le) VALUES (?, ?, NOW() + INTERVAL 30 MINUTE)');
$stmt->execute([$idUtilisateur, hash('sha256', $jeton)]);
// envoi du lien contenant $jeton par mail

// Étape 4 : vérification
$stmt = $pdo->prepare('SELECT id, id_utilisateur FROM reinit_mdp WHERE jeton_hash = ? AND expire_le > NOW() AND utilise = 0');
$stmt->execute([hash('sha256', $_GET['jeton'] ?? '')]);
$demande = $stmt->fetch();
if ($demande === false) {
    exit('Lien invalide ou expiré');
}

Stocker l'empreinte plutôt que le jeton protège les demandes en cours si la table fuite.

SSO, OAuth 2.0 et OpenID Connect en bref

Avec l'authentification unique (SSO, Single Sign-On), l'utilisateur s'authentifie une seule fois auprès d'un fournisseur d'identité (Microsoft Entra ID, Keycloak, Google…) et accède ensuite à plusieurs applications sans ressaisir son mot de passe. Les applications ne voient jamais le mot de passe : elles reçoivent du fournisseur un jeton signé qui atteste de l'identité.

• OAuth 2.0 est un protocole de délégation d'autorisation : il permet à une application d'obtenir un jeton d'accès pour appeler une API au nom de l'utilisateur, avec des droits limités (scopes).
• OpenID Connect (OIDC) ajoute à OAuth 2.0 la couche d'authentification : un jeton d'identité (un JWT) qui dit qui est l'utilisateur.
• Pour une application web ou mobile, le flux recommandé est le code d'autorisation avec PKCE.

Le SSO améliore la sécurité (un seul endroit à protéger par la MFA, un seul compte à désactiver au départ d'un salarié) mais concentre le risque : le compte SSO compromis ouvre toutes les applications. Le sujet E6 SLAM 2024 (aujourd'hui E7) portait sur la mise en place d'un SSO, avec l'analyse d'une erreur invalid_token (corrigé du sujet 2024).

app.post('/api/connexion', async (req, res) => {
  const [lignes] = await pool.execute('SELECT * FROM utilisateur WHERE login = ?', [req.body.login]);
  if (lignes.length === 0) return res.status(404).json({ erreur: 'Utilisateur inconnu' });
  if (lignes[0].mdp !== req.body.mdp) return res.status(401).json({ erreur: 'Mot de passe incorrect' });
  const jeton = jwt.sign({ id: lignes[0].id, role: lignes[0].role, email: lignes[0].email }, 'gsb');
  res.json({ jeton });
});

app.post('/api/connexion', limiteConnexion, async (req, res) => {
  const { login, mdp } = req.body;
  if (typeof login !== 'string' || typeof mdp !== 'string') return res.status(400).end();
  const [lignes] = await pool.execute(
    'SELECT id, role, mdp_hash FROM utilisateur WHERE login = ? AND actif = 1', [login]);
  const utilisateur = lignes[0];
  const valide = await argon2.verify(utilisateur?.mdp_hash ?? HASH_FACTICE, mdp);
  if (!utilisateur || !valide) {
    journaliser('connexion', login, req.ip, 'echec');
    return res.status(401).json({ erreur: 'Identifiant ou mot de passe incorrect' });
  }
  journaliser('connexion', login, req.ip, 'succes');
  const jeton = jwt.sign({ sub: String(utilisateur.id), role: utilisateur.role },
    process.env.JWT_SECRET, { algorithm: 'HS256', expiresIn: '15m' });
  res.json({ jeton });
});

Pour aller plus loin. Le cours Authentification et habilitations va plus loin sur la MFA, les passkeys, les sessions et JWT et OAuth 2.0 et OpenID Connect.