Chapitre 4.3 — MFA, TOTP & passkeys

⏱️ TL;DR — La MFA (authentification multifacteur) combine plusieurs preuves de types différents : ce que tu sais (mot de passe), ce que tu possèdes (téléphone, clé), ce que tu es (biométrie). Un mot de passe volé ne suffit alors plus. Le TOTP (codes à 6 chiffres d’une app comme Google Authenticator) est simple et solide, mais hameçonnable. Le SMS est le facteur le plus faible (SIM swap, interception) — à éviter si possible. L’avenir, ce sont les passkeys (WebAuthn/FIDO2) : une clé cryptographique liée à l’appareil, résistante au phishing par conception, qui peut carrément remplacer le mot de passe. Prévois toujours des codes de secours.

🎯 Objectifs

• Définir la MFA et les trois catégories de facteurs.
• Comprendre le TOTP (fonctionnement, forces, limite : phishing) et pourquoi le SMS est faible.
• Comprendre les passkeys/WebAuthn et leur résistance native au phishing.
• Gérer les à-côtés : codes de secours, récupération, où exiger la MFA.

Les trois facteurs

L’authentification multifacteur exige au moins deux preuves de catégories différentes :

Le mot « différentes » est essentiel : deux mots de passe ne font pas une MFA (même catégorie). L’intérêt : pour usurper l’identité, un attaquant devrait compromettre deux canaux indépendants — bien plus dur que voler un seul mot de passe. C’est la mesure qui neutralise le bruteforce et le credential stuffing (chapitre 4.2).

TOTP : les codes à 6 chiffres

Le TOTP (Time-based One-Time Password) est le second facteur le plus répandu. À l’activation, le serveur et l’app d’authentification (Google Authenticator, Authy, FreeOTP…) partagent un secret (souvent via un QR code). Ensuite, l’app dérive un code à 6 chiffres à partir de ce secret et de l’heure courante ; le code change toutes les ~30 secondes. À la connexion, l’utilisateur saisit le code affiché ; le serveur le recalcule et compare.

Activation : serveur genere un secret -> QR code -> app le stocke
Connexion  : app calcule TOTP(secret, heure) = 6 chiffres, valable ~30 s
             utilisateur saisit -> serveur recalcule et compare

• Forces : pas de réseau requis côté app (calcul local), secret jamais retransmis, simple à implémenter (bibliothèques standard), bien mieux que rien.
• La limite : le TOTP est hameçonnable. Un site de phishing peut demander le code en temps réel et le rejouer aussitôt sur le vrai site (l’utilisateur tape son mot de passe et son code sur le faux site). Le TOTP élève la barre mais ne résiste pas au phishing en temps réel.

Points d’implémentation : stocker le secret TOTP de façon protégée (chiffré au repos), tolérer une petite dérive d’horloge (fenêtre de ±1 intervalle), et empêcher le rejeu d’un même code.

SMS : le facteur le plus faible

Recevoir un code par SMS est mieux que pas de MFA du tout, mais c’est le facteur le plus faible et il est déconseillé quand une alternative existe :

• SIM swapping : un attaquant convainc l’opérateur de transférer le numéro sur sa carte SIM, et reçoit les codes.
• Interception : les réseaux téléphoniques (SS7) et certains malwares permettent d’intercepter des SMS.
• Dépendance au réseau et à l’opérateur.

⚠️ Piège — « On a mis la MFA par SMS, on est tranquilles. » Le SMS est le maillon faible : le SIM swap est une attaque courante et efficace contre les comptes à valeur. Si tu peux, propose TOTP ou surtout passkeys ; réserve le SMS au repli pour les utilisateurs sans autre option, et protège les opérations sensibles (changement d’email, de MFA) par un facteur plus fort.

Passkeys / WebAuthn : la MFA (et le login) résistant au phishing

Les passkeys reposent sur WebAuthn / FIDO2, un standard qui utilise la cryptographie asymétrique (rappel chapitre 3.2). À l’enregistrement, l’appareil de l’utilisateur (téléphone, ordinateur, clé de sécurité) génère une paire de clés : la privée reste dans l’appareil (souvent protégée par la biométrie), la publique est envoyée au serveur. À la connexion, le serveur envoie un défi que l’appareil signe avec la clé privée ; le serveur vérifie avec la publique.

Ce qui rend les passkeys résistantes au phishing par conception :

• La signature est liée à l’origine (le domaine) : une passkey enregistrée pour formacampus.fr ne fonctionne pas sur formacampuz.fr (le faux site). Même si l’utilisateur est piégé, il ne peut pas authentifier sur le mauvais domaine — le navigateur refuse.
• Rien de « saisissable » ne transite : pas de code que l’utilisateur pourrait taper sur un faux site, pas de secret partagé à voler côté serveur (le serveur ne stocke qu’une clé publique, inutile à un attaquant).

Les passkeys peuvent servir de second facteur ou carrément remplacer le mot de passe (login passwordless). C’est la direction recommandée pour les nouvelles applis. Elles se synchronisent souvent via l’écosystème de l’utilisateur (trousseau) pour l’ergonomie.

💡 Réflexe — Hiérarchie des facteurs, du plus faible au plus fort : SMS < TOTP < passkeys/WebAuthn. Si tu conçois aujourd’hui, vise les passkeys (résistantes au phishing), propose le TOTP en alternative, et n’utilise le SMS qu’en dernier recours. Le vrai saut de sécurité, c’est la résistance au phishing, que seul WebAuthn offre nativement.

Les à-côtés qui font ou défont la MFA

• Codes de secours : à l’activation de la MFA, fournis un jeu de codes de récupération à usage unique (à imprimer/sauver). Sans eux, un utilisateur qui perd son téléphone est verrouillé dehors — et ton support finit par créer une voie de contournement… souvent la faille.
• La récupération est le maillon faible : « J’ai perdu mon second facteur » ne doit pas ouvrir une porte dérobée triviale. Le flux de récupération doit être aussi solide que la MFA elle-même, sinon l’attaquant l’attaque lui.
• Où exiger la MFA : à la connexion, mais aussi (re-demander le facteur) pour les actions sensibles — changer l’email, le mot de passe, désactiver la MFA, opérations à fort impact. C’est la step-up authentication.

🎯 Côté attaquant — Quand la MFA est en place, l’attaquant cesse d’attaquer le mot de passe et vise le maillon le plus faible autour : le phishing en temps réel (piéger le code TOTP), le SIM swap (SMS), le flux de récupération (« mot de passe oublié + MFA perdue »), ou la fatigue MFA (spammer des notifications push jusqu’à ce que la victime approuve). D’où : passkeys (anti-phishing), récupération robuste, et pas de push « approuver ? » en un tap sans contexte.

🧭 Sur FormaCampus — FormaCampus rend la MFA obligatoire pour les formateurs et admins (accès à des données d’apprenants) et fortement encouragée pour tous. Elle propose les passkeys en premier (résistantes au phishing), le TOTP en alternative, et réserve le SMS au repli. Des codes de secours sont générés à l’activation, le flux de récupération est aussi strict que l’auth, et les actions sensibles (changer l’email, désactiver la MFA) exigent une ré-authentification (step-up). Le secret TOTP est chiffré au repos et le rejeu d’un code est bloqué.

✏️ Exercices

Exercice 1 — Est-ce de la MFA ? Pour chaque combinaison, dis si c’est une vraie authentification multifacteur : (a) mot de passe + question secrète ; (b) mot de passe + code TOTP ; (c) empreinte + passkey sur le même téléphone ; (d) mot de passe + passkey.

Exercice 2 — Pourquoi la passkey résiste au phishing. Un utilisateur avec MFA TOTP se fait piéger par formacampuz.fr (faux domaine) et y saisit mot de passe et code. L’attaquant les rejoue sur le vrai site : ça marche. Explique pourquoi, avec une passkey, la même tentative échouerait.

🧠 Quiz de révision

Chapitre suivant : OAuth2 / OIDC & sessions — déléguer l’identité (« se connecter avec Google ») en sécurité, et gérer le cycle de vie des sessions.