La notification push a été adoptée massivement parce qu'elle supprime la saisie d'un code : un message arrive, l'utilisateur appuie sur « Approuver ». C'est précisément cette simplicité qui crée le problème. Approuver devient un réflexe, et un réflexe ne constitue pas une preuve d'intention. Le push corrige l'ergonomie du code à usage unique sans corriger sa faiblesse fondamentale.
Le mécanisme d'attaque : la fatigue, pas la cryptographie
Le push ne se casse pas, il se lasse. L'attaquant qui détient déjà un mot de passe valide déclenche des demandes d'approbation en série, souvent la nuit. La victime finit par approuver pour faire cesser les notifications, ou parce qu'elle croit à un dysfonctionnement. La compromission d'Uber en 2022 a rendu ce scénario public : le facteur a fonctionné exactement comme prévu, et l'attaque a réussi malgré cela.
Deux variantes complètent le tableau :
- La demande contextualisée. Un appel se faisant passer pour le support informatique annonce l'envoi d'une notification « de vérification ». L'utilisateur approuve en confiance. Aucune fatigue n'est nécessaire ; la manipulation suffit.
- Le relais en temps réel. Un proxy inverse capte le mot de passe, déclenche la vraie demande push et récupère la session ouverte. L'utilisateur approuve une connexion qu'il a réellement initiée, sur un domaine qu'il n'a pas vérifié.
Cette troisième variante mérite d'être soulignée, car elle survit aux durcissements les plus courants : la demande est légitime, la victime est réellement en train de se connecter, et l'approbation est sincère.
Ce que chaque durcissement corrige — et ce qu'il laisse ouvert
| Durcissement | Corrige | Ne corrige pas |
|---|---|---|
| Correspondance de nombre (number matching) | approbation réflexe, envois en série | relais en temps réel, manipulation guidée |
| Affichage du contexte (application, lieu, appareil) | connexion manifestement anormale | contexte plausible reproduit par l'attaquant |
| Limitation du nombre de demandes | bombardement de notifications | attaque unique et bien préparée |
| Verrouillage après refus répétés | acharnement | approbation obtenue au premier essai |
| Signalement « ce n'est pas moi » | détection, réponse à incident | la compromission déjà survenue |
| Blocage géographique ou par plage IP | attaques distantes grossières | usage d'un relais local |
| Exigence de déverrouillage biométrique local | approbation par un tiers ayant le téléphone | approbation volontaire de la victime manipulée |
La correspondance de nombre est un progrès net et doit être activée partout où elle existe. Mais elle répond à la question « l'utilisateur regarde-t-il ? », pas à la question « la demande vient-elle du site légitime ? ». Ce second problème n'a pas de solution dans le modèle push, parce que rien ne lie l'approbation au domaine sur lequel la connexion se déroule.
Positionner correctement le push dans une architecture
Le push reste défendable là où il apporte plus qu'il ne coûte :
- Comme signal de détection. Un refus utilisateur est une information de grande valeur : il signale une tentative d'accès avec des identifiants valides. Beaucoup d'organisations ne l'exploitent pas.
- Sur des accès de faible criticité, où l'alternative réaliste serait l'absence de second facteur.
- En couche complémentaire, derrière un facteur lié à l'origine, pour la visibilité et la notification.
Il devient inadapté sur trois périmètres : les accès à privilèges, les parcours de récupération de compte, et la validation d'opérations irréversibles. Sur ces périmètres, une entité soumise à NIS2 ou DORA devra expliquer pourquoi une approbation binaire, non liée au domaine et obtenue par un simple appui, constitue une mesure proportionnée.
Du « oui/non » à la preuve d'intention
Le défaut de conception du push tient en une phrase : il demande un consentement, pas une preuve. Un consentement s'obtient par lassitude, par confiance ou par erreur ; une preuve suppose une action que seul l'utilisateur légitime peut produire.
Trois trajectoires d'amélioration, par exigence croissante :
| Trajectoire | Principe | Ce qu'elle change |
|---|---|---|
| Push durci | correspondance de nombre, contexte riche, limitation | élimine l'approbation aveugle |
| Facteur lié à l'origine | passkey ou clé physique en méthode principale | supprime le relais par proxy inverse |
| Preuve cognitive sur l'action | l'utilisateur résout un challenge appris, portant sur l'opération | rend l'approbation non délégable et non réflexe |
La troisième ligne est le principe du 4ᵉ facteur « je sais faire » : au lieu de demander « acceptez-vous ? », le système demande une action que l'attaquant ne peut ni exécuter à distance, ni obtenir par persuasion, ni rejouer. Sur une opération sensible, c'est la différence entre une case cochée et une intention établie.
Migrer sans casser l'exploitation
Le push est souvent le second facteur historique d'une organisation, avec un parc entier déjà enrôlé. Le retrait brutal est rarement réaliste. Une séquence pragmatique :
- Activer immédiatement la correspondance de nombre et l'affichage du contexte sur tout le parc.
- Traiter les refus utilisateurs comme des alertes de sécurité, avec une procédure associée.
- Retirer le push des comptes à privilèges en priorité, au profit d'un facteur lié à l'origine.
- Retirer le push des parcours de récupération et de validation d'opérations.
- Conserver le push, le cas échéant, comme canal de notification et de détection.
FAQ
La correspondance de nombre suffit-elle à sécuriser le push ?
Elle supprime l'approbation réflexe et rend le bombardement inefficace, ce qui est un gain réel. Elle ne protège ni du relais en temps réel, ni de la manipulation par un faux support qui dicte le nombre à saisir.
Faut-il désactiver le push après un incident de MFA fatigue ?
Sur les comptes concernés et sur les comptes à privilèges, oui. Sur l'ensemble du parc, un retrait sans alternative prête peut dégrader la posture globale. Séquencez par population plutôt que de basculer d'un bloc.
Le push est-il conforme aux exigences d'authentification forte ?
Il relève de la possession et peut compter comme un facteur. La question réglementaire porte plutôt sur la proportionnalité au risque : sur une opération de paiement, la DSP2 exige en outre un lien dynamique avec le montant et le bénéficiaire, qu'une approbation binaire ne fournit pas.
Comment mesurer l'exposition à la MFA fatigue ?
En instrumentant trois indicateurs : nombre de demandes par utilisateur et par jour, taux de refus, et délai entre l'envoi et l'approbation. Un délai très court, systématique, indique une approbation réflexe généralisée.
Aller plus loin : pilier : authentification cognitive · MFA fatigue et push bombing · sécuriser la connexion avec passkey · le 4ᵉ facteur contre la MFA fatigue