Chapitre 4.2 — Mots de passe & connexion

⏱️ TL;DR — Un flux de connexion solide, c’est plus que « comparer un mot de passe ». Côté politique : suivre les recommandations modernes (NIST) — privilégier la longueur, autoriser les phrases de passe, bannir les mots de passe compromis connus, et abandonner les règles absurdes (changement forcé tous les 90 jours, complexité type « 1 majuscule + 1 chiffre + 1 symbole »). Côté attaques : limiter le bruteforce (rate limiting, verrouillage temporisé, captcha après N échecs), contrer le credential stuffing (MFA, détection), et ne pas fuiter quels comptes existent (messages et timings uniformes). Le stockage, lui, est déjà réglé : argon2id (Partie 3).

🎯 Objectifs

• Définir une politique de mot de passe moderne (NIST) et abandonner les mauvaises habitudes.
• Comprendre et bloquer le bruteforce (rate limiting, verrouillage, captcha).
• Comprendre le credential stuffing et ses parades (MFA, mots de passe compromis).
• Éviter l’énumération de comptes (messages d’erreur et timings uniformes).

Une politique de mot de passe moderne (NIST)

Les vieilles règles de « complexité » ont fait la preuve de leur contre-productivité : forcer « 1 majuscule, 1 chiffre, 1 symbole » pousse les gens vers Password1! (faible et prévisible) ; imposer un changement tous les 90 jours produit Password1! → Password2!. Les recommandations modernes (résumées par le NIST) inversent la logique :

📚 La source — Les recommandations précises (longueurs, modalités) évoluent : la référence est le NIST SP 800-63B (Digital Identity Guidelines) et l’OWASP Authentication Cheat Sheet. On retient ici l’esprit — longueur > complexité, bannir les compromis connus, pas de rotation forcée, MFA — plutôt qu’un seuil chiffré qui bougera. La liste des mots de passe compromis se vérifie via des services de type Pwned Passwords (avec un modèle k-anonymity qui n’envoie pas le mot de passe complet).

Bloquer le bruteforce

Le bruteforce consiste à essayer un grand nombre de mots de passe sur un compte. Sans limite, un attaquant peut tester des milliers de candidats par minute. Les parades, en couches :

• Rate limiting : limiter le nombre de tentatives par IP et par compte sur une fenêtre de temps (ex. quelques essais par minute), puis ralentir/refuser.
• Verrouillage temporisé progressif : après N échecs, imposer un délai croissant (back-off exponentiel) plutôt qu’un blocage définitif (qui deviendrait un déni de service : un attaquant verrouille volontairement le compte d’autrui).
• Captcha / preuve de travail après quelques échecs, pour couper les bots.
• MFA : même un mot de passe deviné ne suffit plus (chapitre 4.3).
• Hachage lent (argon2id) : rend chaque tentative coûteuse côté attaquant s’il a volé la base (bruteforce hors-ligne).

⚠️ Piège — Un verrouillage définitif après N échecs est une fausse bonne idée : il transforme la protection en arme — un attaquant qui connaît des emails peut verrouiller tous les comptes à volonté (déni de service). Préfère un ralentissement progressif (délais croissants, captcha), un rate limiting par IP+compte, et surtout la MFA, qui rend le bruteforce du seul mot de passe insuffisant.

Contrer le credential stuffing

Le credential stuffing est différent du bruteforce : l’attaquant ne devine pas, il rejoue des couples email/mot de passe volés ailleurs (fuites d’autres sites). Comme les gens réutilisent leurs mots de passe, un pourcentage non négligeable de ces couples fonctionne. C’est massif, automatisé, et le rate limiting par compte n’y suffit pas (un essai par compte, sur des millions de comptes).

Parades spécifiques :

• MFA : la défense reine — le mot de passe volé ne donne pas accès sans le second facteur.
• Vérifier les mots de passe compromis à l’inscription et au changement (refuser ceux connus dans des fuites).
• Détection comportementale : pics de connexions échouées depuis de nombreuses IP, alertes.
• Rate limiting par IP / device fingerprint, et surveillance des schémas de trafic.

Ne pas fuiter quels comptes existent (énumération)

Un détail qui compte : le flux de connexion (et de reset, d’inscription) ne doit pas révéler si un email existe dans ta base. Sinon, un attaquant énumère les comptes valides avant de les cibler.

# ❌ Fuite : deux messages differents
"Cet email n'existe pas."          <- l'attaquant sait que le compte n'existe PAS
"Mot de passe incorrect."          <- ... et la, qu'il EXISTE

# ✅ Message unique, quelle que soit la cause
"Identifiants incorrects."

Deux vecteurs de fuite à neutraliser :

• Le message : toujours le même (« identifiants incorrects »), que l’email existe ou non.
• Le timing : si « email inexistant » répond en 5 ms et « mot de passe faux » en 300 ms (car on a haché), la différence de temps trahit l’existence. Parade : effectuer un travail comparable dans les deux cas (par ex. hacher un mot de passe factice quand l’utilisateur n’existe pas) pour uniformiser le temps de réponse.

Idem pour l’inscription (« cet email est déjà utilisé » énumère) et le reset (« si un compte existe, un email a été envoyé » plutôt que « aucun compte avec cet email »).

🎯 Côté attaquant — Avant de bruteforcer, l’attaquant cartographie : il envoie des emails au login et au reset et compare messages et temps de réponse pour dresser la liste des comptes réels. Chaque différence observable — un mot près, quelques millisecondes — est une fuite exploitable. La parade est l’uniformité systématique : même réponse, même temps, même comportement, que le compte existe ou non.

💡 Réflexe — Trois réflexes pour tout formulaire d’auth : (1) message générique unique, (2) temps de réponse uniforme (travail équivalent dans tous les cas), (3) rate limiting. Ils se pensent ensemble, dès la conception du endpoint — pas après coup.

🧭 Sur FormaCampus — Le login de FormaCampus applique le lot complet : politique NIST (longueur privilégiée, phrases de passe autorisées, mots de passe compromis refusés à l’inscription, pas de rotation forcée), rate limiting par IP + compte avec back-off progressif (jamais de verrouillage définitif), captcha après plusieurs échecs, et MFA proposée (obligatoire pour les rôles formateur/admin). Les messages sont uniformes (« identifiants incorrects ») et le endpoint hache un mot de passe factice quand l’email est inconnu, pour un timing constant. Le reset répond toujours « si un compte existe, un email a été envoyé ».

✏️ Exercices

Exercice 1 — Répare la politique. Une appli impose : mot de passe de 8 caractères exactement, avec 1 majuscule + 1 chiffre + 1 symbole, changé tous les 90 jours, collage désactivé. Cite trois problèmes et propose une politique moderne.

Exercice 2 — Traque la fuite. Ce endpoint de login répond 404 "utilisateur inconnu" si l’email n’existe pas, et 401 "mot de passe incorrect" sinon. En plus, le premier cas répond en ~3 ms, le second en ~250 ms. Quels sont les deux problèmes et comment corriger ?

🧠 Quiz de révision

Chapitre suivant : MFA, TOTP & passkeys — ajouter un second facteur, des codes TOTP aux passkeys qui suppriment carrément le mot de passe.