Qu'est-ce que l'authentification multifacteur (MFA) ?

L’authentification multifacteur est un contrôle de connexion qui exige deux preuves ou plus de types différents — ce que vous savez, avez ou êtes. Le mot différents porte tout le poids et se rate souvent : un mot de passe plus une question secrète, ce sont deux preuves d’une seule catégorie — la connaissance — et donc pas de la MFA du tout. L’idée est combinatoire : un mot de passe hameçonné ne tient pas votre téléphone ; un téléphone volé ne connaît pas votre code PIN ; le vol de chaque facteur laisse l’attaquant à court d’une catégorie.

Points clés

Comment fonctionne réellement TOTP

L’app d’authentification, démystifiée — aucune page de classement n’explique la machinerie (RFC 6238) :

Enrôlement       QR code = otpauth://totp/app:ada?secret=JBSWY3DP…
                 → l'app partage désormais un SECRET Base32 avec le serveur

Toutes les 30 s  les deux côtés calculent, indépendamment et hors ligne :
                 code = truncate( HMAC-SHA1( secret, floor(unix_time / 30) ) ) % 10⁶

Connexion        vous tapez les 6 chiffres de l'app ; le serveur calcule les siens,
                 accepte ±1 fenêtre de temps pour la dérive d'horloge → égalité = possession prouvée

Comment brancher cela dans le flux de connexion d’une app :

// JavaScript / Node.js — Back4app JS SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
await currentUser.save({
  authData: { mfa: { secret: totpSecret, token: codeFromApp } },
});
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
const user = await Parse.User.logIn('ada', password, {
  authData: { mfa: { token: codeFromApp } },
});

// Flutter / Dart — Back4app Flutter SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
currentUser.set('authData', {
  'mfa': {'secret': totpSecret, 'token': codeFromApp},
});
await currentUser.save();
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
final user = ParseUser('ada', password, null)
  ..set('authData', {'mfa': {'token': codeFromApp}});
await user.login();

// iOS / Swift — Back4app Swift SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
let enrolled = try await currentUser.link("mfa",
    authData: ["secret": totpSecret, "token": codeFromApp])
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
let user = try await User.login("ada", password: password,
    authData: ["mfa": ["token": codeFromApp]])

// Android / Kotlin — Back4app Android SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
val enroll = mapOf("secret" to totpSecret, "token" to codeFromApp)
ParseUser.getCurrentUser().linkWithInBackground("mfa", enroll)
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
val authData = mapOf("token" to codeFromApp)
ParseUser.logInWithInBackground("mfa", authData) // paired with the password check

MFA vs. 2FA

Un tableau suffit à trancher ; la vraie question est quels facteurs — car le plafond de sécurité n’est pas fixé par le nombre de preuves empilées, mais par le fait que l’une d’elles soit hameçonnable ou non.

Le classement des méthodes, honnêtement

La comparaison que publient les recommandations de la CISA et que les explications commerciales évitent — quelles attaques battent quelles méthodes :

Le motif de la colonne de gauche, c’est toute l’histoire moderne : tout code et toute approbation peuvent être relayés par un proxy d’hameçonnage ; seule la cryptographie liée à l’origine survit au contact d’une fausse page de connexion.

Les attaques, en clair

Hameçonnage adversary-in-the-middle : des kits proxy open-source se placent entre la victime et le vrai site, relaient en direct le mot de passe et le code à usage unique, puis gardent le cookie de session obtenu — MFA “réussie”, compte perdu. Push bombing : avec un mot de passe volé, on inonde de demandes d’approbation jusqu’à ce que la fatigue en emporte une ; la correspondance de nombres (taper les chiffres affichés à l’écran) supprime le chemin de l’approbation machinale. SIM swapping : convaincre un opérateur de transférer le numéro de la victime, puis recevoir ses codes SMS — l’attaque qui a placé le SMS au bas du tableau. Le fil commun : ces attaques battent les facteurs qui peuvent être racontés à quelqu’un ; elles échouent toutes face à des facteurs qui ne parlent cryptographiquement qu’à l’origine authentique.

Le problème de la récupération

Tout déploiement de MFA crée une seconde porte : que se passe-t-il quand le téléphone est perdu ? Les codes de secours — à usage unique, générés à l’enrôlement, conservés hors ligne — sont la réponse standard ; les flux de récupération de compte sont la réponse dangereuse. Si un appel au support ou une réinitialisation par e-mail suffit à retirer la MFA, l’attaquant appelle le support — la technique derrière des brèches très médiatisées — et votre contrôle le plus fort est écrasé par votre processus le plus faible. La règle : la récupération doit exiger une assurance égale ou supérieure à la connexion qu’elle remplace — plusieurs méthodes enrôlées, vérification renforcée pour les réinitialisations, et retrait de la MFA traité comme un événement privilégié, journalisé et générateur d’alerte.

Quelle est vraiment l’efficacité de la MFA ?

Deux affirmations vraies, souvent confondues. Face aux attaques automatisées — credential stuffing, password spraying — la protection de la MFA est quasi totale : les fameux chiffres de 99 % viennent de télémétries de connexion à grande échelle qui mesurent exactement cela, et un travail relu par des pairs a retrouvé une réduction des compromissions d’environ 99 % dans le même périmètre. Face à l’hameçonnage ciblé avec proxy temps réel, la MFA par code ou par push est démontrablement contournable, ce qui explique pourquoi les critiques donnent une efficacité tous-attaques bien plus basse et pourquoi les agences poussent aujourd’hui spécifiquement les méthodes résistantes à l’hameçonnage. La synthèse honnête : n’importe quelle MFA met fin à l’ère du mot de passe suffisant ; seule la MFA de classe passkey met fin à l’hameçonnage. Déployez une MFA partout, et la MFA résistante à l’hameçonnage partout où les enjeux justifient la friction d’enrôlement.

Cas d’usage courants

• Protéger l’émission de compte — la MFA garde le moment où sessions et tokens sont émis ; tout ce qui suit fait confiance à cette barrière.
• Renforcement pour les actions sensibles — redemander au moment du paiement, d’une suppression ou d’un export de clés, pas seulement à la connexion.
• Comptes admin et à privilèges — là où la MFA devrait être obligatoire et résistante à l’hameçonnage, sans exception.
• Régimes de conformité — les cadres du paiement, de la santé et du secteur public exigent de plus en plus la MFA purement et simplement.
• Compléter la connexion sociale — héritée du fournisseur d’identité, ou imposée localement pour les actions à forte valeur.

Quelle méthode MFA proposer ? Matrice de décision

Limites et trade-offs

• La friction est réelle et mesurable. Chaque invite coûte de la conversion et des tickets de support ; une sollicitation adaptative, fondée sur le risque, dépense la friction là où le risque se trouve.
• La MFA hameçonnable rapporte moins qu’il n’y paraît. Face à une attaque par proxy ciblée, codes et push tombent ; traitez-les comme des bloqueurs d’automatisation, pas comme une armure anti-hameçonnage.
• Le téléphone est un point de défaillance unique. La perte d’appareil sans plan de récupération devient un blocage à grande échelle — l’UX d’enrôlement doit planter des méthodes de secours dès le premier jour.
• Les flux de récupération inversent le calcul. Un chemin de réinitialisation faible plafonne silencieusement tout votre dispositif à sa propre solidité.
• L’enrôlement est la falaise de l’adoption. Les obligations sans flux QR fluides ni replis clairs génèrent de la résistance ; le meilleur dispositif est celui que les utilisateurs terminent vraiment.

La MFA sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. TOTP arrive comme de la configuration, pas de la construction : l’adaptateur d’authentification mfa de Back4app active les codes temporels avec un bloc de configuration — chiffres, période et algorithme réglables — et les onglets de code montrent toute l’histoire côté client : l’enrôlement prouve la possession en appariant le secret partagé avec un code valide, le serveur émet des codes de récupération à usage unique, et les connexions suivantes associent le mot de passe aux six chiffres du moment. Comme les sessions de la plateforme sont révocables côté serveur, l’hygiène qui entoure tout cela tient aussi : un changement de MFA peut terminer immédiatement les autres sessions, et les triggers Cloud Code sont l’endroit naturel pour journaliser les événements d’enrôlement et conditionner le retrait de la MFA à des contrôles renforcés — la discipline de récupération défendue dans cet article, exprimée en quelques fonctions.