Authentification et contrôle d'accès

Le 7 mai 2021, Colonial Pipeline arrête le principal oléoduc de la côte est des États-Unis. Pénuries de carburant dans dix-sept États, état d'urgence fédéral, 4,4 millions de dollars de rançon. Le point d'entrée : un compte VPN inactif, encore valide, dont le mot de passe figurait dans une fuite antérieure, et qui n'était pas protégé par une authentification multifacteur.

Aucune vulnérabilité logicielle n'a été exploitée. Aucun chiffrement n'a été cassé. Un attaquant s'est authentifié — correctement, du point de vue du système — avec des identifiants valides.

C'est le cas général plutôt que l'exception. Le contrôle d'accès est la fonction de sécurité la plus sollicitée d'un système : à chaque requête, il faut décider qui parle et ce qu'il a le droit de faire. Ce chapitre traite les deux questions, dans cet ordre, et l'ordre n'est pas négociable.

Trois mots que l'on confond, et ce que la confusion coûte

L'identification n'est pas une preuve : une adresse de courriel est publique. La confondre avec l'authentification produit la faille classique du « lien de réinitialisation envoyé à l'adresse saisie » — où c'est l'attaquant qui choisit l'adresse.

L'autorisation est distincte de l'authentification et se vérifie à chaque requête, côté serveur. Un utilisateur authentifié n'est pas un utilisateur autorisé. C'est la confusion la plus coûteuse du domaine : elle produit la première catégorie de l'OWASP Top 10, que le chapitre 7 exploitera pour de bon.

Une note pratique sur l'énumération de comptes : si le formulaire répond « ce compte n'existe pas » puis « mot de passe incorrect », il vient de dire à l'attaquant quels comptes existent — et transforme une attaque à l'aveugle en attaque ciblée. La réponse doit être identique, en texte comme en temps de réponse, dans les deux cas.

Les facteurs, et pourquoi il en faut plusieurs

Un facteur d'authentification appartient à l'une de trois catégories :

• ce que l'on sait : mot de passe, code PIN, question secrète ;
• ce que l'on possède : téléphone, clé matérielle, carte à puce ;
• ce que l'on est : empreinte, visage, voix.

Une authentification est multifacteur quand elle combine des catégories différentes. Un mot de passe suivi d'une question secrète n'est pas du MFA : les deux relèvent du savoir, et les mêmes fuites les emportent ensemble.

Tous les seconds facteurs ne se valent pas, et l'écart est plus grand qu'on ne l'imagine.

La colonne décisive est la troisième. TOTP et SMS transmettent un secret que l'utilisateur peut recopier ailleurs ; une clé FIDO2 lie cryptographiquement la réponse au domaine qui la demande, ce qu'aucun site de hameçonnage ne peut contourner. C'est la seule technologie de ce chapitre qui supprime une classe entière d'attaques au lieu de la rendre plus coûteuse.

Cela ne rend pas le SMS inutile : un MFA faible vaut infiniment mieux que pas de MFA du tout, et il aurait suffi à empêcher Colonial Pipeline. La hiérarchie sert à choisir où investir, pas à refuser l'intermédiaire.

Comment tombent les mots de passe

Quatre attaques, souvent confondues, aux contre-mesures différentes.

La force brute essaie tout l'espace. Elle n'est réaliste que hors ligne, sur une base volée. En ligne, dix essais par minute la rendent absurde.

L'attaque par dictionnaire essaie des mots de passe probables — listes de fuites, mutations connues. Elle réussit parce que les humains choisissent mal : Printemps2026! satisfait toutes les règles de composition et figure dans toutes les listes.

Le bourrage d'identifiants rejoue des couples adresse/mot de passe issus d'autres fuites. Il exploite la réutilisation, et c'est aujourd'hui l'attaque la plus rentable : la victime a un mot de passe excellent, mais le même partout.

La pulvérisation inverse la boucle : un seul mot de passe très probable, essayé sur des milliers de comptes. Un compte ne voit qu'un essai, ce qui la rend invisible à tout verrouillage par compte.

Les tables arc-en-ciel ne sont pas une attaque distincte mais un compromis temps-mémoire : on précalcule pour ne plus calculer. Le sel du chapitre 2 les a rendues obsolètes — et c'est précisément pour cela qu'il existe.

Les défenses, dans l'ordre d'efficacité :

1. Un stockage lent et salé — chapitre 2. C'est le seul levier qui agit sur tous les comptes à la fois, et il ne dépend pas des utilisateurs.
2. La comparaison aux mots de passe compromis à la création. Refuser les mots de passe déjà présents dans les fuites publiques élimine l'essentiel du dictionnaire et du bourrage.
3. La limitation de débit, par compte et par adresse source, avec un délai croissant. Le verrouillage dur crée un déni de service ; le ralentissement progressif, non.
4. Le MFA, qui rend l'ensemble largement théorique — un mot de passe volé ne suffit plus.
5. La détection : pulvérisation, connexions impossibles géographiquement, comptes dormants réactivés. C'est ce dernier point qui manquait à Colonial Pipeline.

Ce que les recommandations actuelles — NIST SP 800-63B, ANSSI — ont abandonné, et qu'il faut cesser d'exiger : les règles de composition obligatoires (une majuscule, un chiffre, un symbole) et l'expiration périodique. Les deux dégradent mesurablement la sécurité, parce qu'elles poussent vers des motifs prévisibles. On demande désormais de la longueur — douze caractères au minimum — et l'absence dans les listes de compromission.

Sessions et jetons

Une fois l'utilisateur authentifié, on ne redemande pas le mot de passe à chaque requête : on lui remet un jeton de session. Ce jeton devient l'équivalent du mot de passe pour toute sa durée de vie — et il se protège comme tel.

Ce qu'un identifiant de session doit être : imprévisible (au moins 128 bits d'un générateur cryptographique — jamais un compteur, jamais l'identifiant de l'utilisateur), transmis uniquement en HTTPS, stocké dans un cookie portant les attributs HttpOnly (inaccessible au JavaScript, donc au vol par XSS), Secure et SameSite.

Trois règles de cycle de vie, chacune répondant à une attaque précise :

• Régénérer l'identifiant à la connexion, et à tout changement de privilège. Sans cela, l'attaquant fixe d'avance la valeur du cookie dans le navigateur de la victime, attend qu'elle se connecte, et hérite d'une session authentifiée : c'est la fixation de session.
• Expirer : une durée absolue et une durée d'inactivité. Une session éternelle est un mot de passe éternel.
• Révoquer réellement à la déconnexion, côté serveur. Supprimer le cookie du navigateur n'invalide rien pour qui l'avait déjà copié.

Le cas des JWT mérite un mot, parce qu'il est mal compris. Un JWT est un jeton auto-porté : le serveur ne stocke rien, il vérifie une signature. C'est commode pour répartir la charge, et cela crée un problème réel : on ne peut pas révoquer ce qu'on ne stocke pas. Un JWT volé reste valide jusqu'à son expiration, quoi qu'il arrive — compte supprimé, droits retirés, mot de passe changé. La parade habituelle est une durée de vie très courte accompagnée d'un jeton de rafraîchissement, lui, révocable. Le chapitre 7 reprendra les JWT côté attaque, où ils échouent surtout par vérification de signature incomplète.

Autoriser : quatre modèles

L'autorisation répond à « ce sujet peut-il faire cette action sur cet objet ? ». Quatre modèles, du plus souple au plus rigide.

Les permissions Unix — propriétaire, groupe, autres — sont du DAC : le propriétaire d'un fichier décide qui le lit, et rien n'empêche un utilisateur de tout ouvrir en lecture. SELinux et AppArmor ajoutent une couche MAC par-dessus : même root ne franchit pas une règle interdite par la politique, ce qui limite les dégâts d'un processus compromis. Le chapitre 4 y revient.

Le RBAC est ce que vous implémenterez en pratique. Sa maladie chronique est la dérive de privilèges : un employé change trois fois de poste, accumule trois jeux de rôles, et finit avec des droits que personne n'a jamais décidé de lui donner. Le remède n'est pas technique mais organisationnel — une revue périodique des habilitations, dont le chapitre 10 fait une exigence de gouvernance.

Moindre privilège, et séparation des tâches

Deux principes, souvent cités ensemble, qui ne répondent pas à la même menace.

Le moindre privilège : chaque sujet reçoit exactement les droits nécessaires à sa fonction, pour la durée nécessaire, et rien de plus. Il ne prévient pas l'intrusion — il borne son rayon d'action. Une application web compromise qui tourne sous un compte dédié sans droit d'écriture sur son propre code n'offre à l'attaquant qu'une fraction de ce qu'un compte administrateur lui aurait donné. C'est le principe qui décide de l'ampleur d'un incident, et c'est pourquoi il traverse tout ce cours.

La séparation des tâches : aucune personne seule ne doit pouvoir mener à terme une opération critique. Celui qui saisit un virement ne l'approuve pas ; celui qui écrit le code ne le déploie pas en production seul. Elle répond à la menace interne du chapitre 1, celle contre laquelle aucune défense périmétrique ne peut rien.

À vous

La politique de mot de passe est le seul sujet de ce cours où l'intuition commune est mesurablement fausse. Plutôt que de l'affirmer, calculez.

L'exercice vous fait estimer l'entropie de quatre secrets, puis le temps nécessaire pour les casser dans trois scénarios : base volée hachée en SHA-256, base volée hachée en bcrypt, et attaque en ligne limitée à dix essais par minute. Vous en tirerez la politique à écrire — et elle ne ressemble pas à celle de votre banque.

// Combien de temps tient un mot de passe ? La question n'a pas de réponse
// tant qu'on n'a pas dit CONTRE QUOI. Trois scénarios, trois ordres de
// grandeur — et la même politique de mot de passe n'y répond pas.

// Débits observés en 2024 sur une seule carte graphique de bureau.
const SCENARIOS = [
  { nom: "hors ligne, base en SHA-256", essaisParSeconde: 1e10 },
  { nom: "hors ligne, base en bcrypt (coût 12)", essaisParSeconde: 2e4 },
  { nom: "en ligne, 10 essais par minute", essaisParSeconde: 10 / 60 },
];

const CANDIDATS = [
  { mdp: "Passw0rd!",        alphabet: 95, longueur: 9 },
  { mdp: "chat",             alphabet: 26, longueur: 4 },
  { mdp: "correcte-agrafe-batterie-crampon", alphabet: 0, longueur: 0 }, // à traiter
  { mdp: "aX7#kL2@qR9",      alphabet: 95, longueur: 11 },
];

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. entropie() : le nombre de bits d'un mot de passe tiré au hasard dans un
//    alphabet de taille A et de longueur L. (Indice : log2 de A puissance L.)
// 2. delai() : le temps MOYEN pour le trouver par force brute — on tombe
//    dessus à la moitié de l'espace en moyenne.
// 3. La phrase de passe est tirée au hasard dans un dictionnaire de 7776
//    mots (4 mots). Quel alphabet, quelle longueur ?

function entropie(alphabet, longueur) {
  return 0; // à compléter
}

function delai(bits, essaisParSeconde) {
  return 0; // secondes ; à compléter
}

// ── Affichage ─────────────────────────────────────────────────────────────
function lisible(secondes) {
  const u = [["s", 60], ["min", 60], ["h", 24], ["j", 365], ["ans", 1e9]];
  let v = secondes, i = 0;
  while (i < u.length - 1 && v >= u[i][1]) { v /= u[i][1]; i++; }
  return v.toExponential(1) + " " + u[i][0];
}

for (const c of CANDIDATS) {
  const bits = entropie(c.alphabet, c.longueur);
  console.log("\n" + c.mdp + "  (" + bits.toFixed(0) + " bits)");
  for (const s of SCENARIOS) {
    console.log("   " + s.nom.padEnd(38) + lisible(delai(bits, s.essaisParSeconde)));
  }
}

Ce que la suite en fait

Ce chapitre a traité le contrôle d'accès comme une abstraction : sujets, objets, permissions. Le chapitre 4 le regarde là où il s'implémente réellement — les permissions Unix et les jetons d'accès Windows — et surtout là où il se contourne : l'escalade de privilèges, qui est la matérialisation exacte de la phase 4 de la chaîne d'attaque.

Le chapitre 7 reprendra les sessions et les jetons côté attaquant : vol de cookie par XSS, CSRF, JWT mal vérifiés, contrôle d'accès défaillant. Vous y verrez que la première faille de l'OWASP Top 10 n'est pas une faiblesse d'authentification mais d'autorisation — précisément la distinction posée au début de ce chapitre.

À retenir