L’attaquant qui a pénétré Uber n’a pas cassé la MFA. Il a exploité la décision qui l’avait rendue insupportable pour les utilisateurs. La vulnérabilité n’était pas dans le code, elle était dans l’arbitrage.
Un système MFA renforcé contourné en 10 minutes
Un attaquant de 18 ans a obtenu un accès complet aux systèmes internes d’Uber : outils de sécurité, infrastructure cloud, code source, données sensibles. Le vecteur d’entrée n’était pas une faille technique dans le système MFA, pourtant considéré comme robuste. C’était un employé épuisé par le push bombing.
Le mécanisme : l’attaquant a envoyé des dizaines de notifications d’authentification jusqu’à ce que l’employé, submergé, valide par lassitude. Puis il s’est fait passer pour le support IT via WhatsApp : « Tu reçois des notifications parce qu’il y a un problème de sécurité, valide la prochaine pour qu’on puisse régler ça ».
L’authentification multi-facteurs est devenue un standard : mot de passe + code SMS, mot de passe + application d’authentification, mot de passe + clé physique. Sur le papier, c’est une évidence : multiplier les barrières réduit les intrusions. Dans la réalité organisationnelle, l’histoire est plus complexe. Chaque couche de sécurité supplémentaire produit un effet secondaire : la friction. Dans un système humain sous pression, celle-ci génère des contournements.
Ce paradoxe n’est pas un problème informatique. C’est un problème de décision systémique, et il appartient au dirigeant, pas au DSI.
La décision du dirigeant vs la réalité du terrain
Les directions IT raisonnent en termes de probabilité d’attaque : plus il y a d’étapes d’authentification, plus il est difficile d’accéder au système. Ce raisonnement est techniquement correct. Mais il néglige une variable centrale : le comportement adaptatif des utilisateurs.
Dans un système humain, toute contrainte excessive produit une réponse compensatoire laquelle est souvent invisible jusqu’à l’incident. Le dirigeant qui valide un renforcement sécuritaire sans modéliser cette réponse prend une décision incomplète. Il a résolu un problème technique en créant un problème comportemental.
C’est le même mécanisme que Nokia validant des actions marketing sans toucher à son architecture décisionnelle, ou qu’une direction générale annonçant un repositionnement premium sans modifier les incitations des commerciaux. La solution tentée aggrave le problème qu’elle voulait résoudre.
La boucle sécurité / contournement
La dynamique est constante dans les organisations : une faille survient, l’organisation renforce la sécurité, les utilisateurs rencontrent des frictions quotidiennes, ils développent des raccourcis, ces raccourcis créent de nouvelles vulnérabilités, l’organisation renforce encore. La boucle se referme.
Ce n’est pas un problème technique. C’est un problème d’interaction entre système technique et système humain, une propriété émergente d’une décision prise au mauvais niveau d’analyse.
Six cas d’entreprise révélateurs
Une entreprise impose des mots de passe complexes renouvelés tous les 60 jours, couplés à un code SMS. Résultat : les collaborateurs notent leurs identifiants sur papier. La sécurité formelle augmente. La sécurité réelle diminue.
Dans une PME industrielle, l’accès au logiciel de gestion nécessite un code sur smartphone personnel. Certains employés refusent d’utiliser leur téléphone privé. Un seul numéro est alors utilisé pour plusieurs comptes. Un facteur censé individualiser l’accès devient mutualisé.
Dans une équipe support, la double authentification ralentit la prise en charge des tickets. Un compte générique partagé est créé pour aller plus vite. La traçabilité disparaît.
Dans une entreprise internationale, chaque outil impose sa propre méthode MFA. Les collaborateurs accumulent les notifications. Certains valident mécaniquement sans vérifier l’origine. Le phishing par validation devient possible. C’est exactement le mécanisme exploité chez Uber.
Une organisation déploie la MFA sur VPN. Les salariés en télétravail rencontrent des blocages techniques. Certains désactivent les mises à jour de sécurité pour éviter les incompatibilités. La couche supplémentaire génère une faille latérale.
Plus la sécurité est stricte, plus le support IT devient central. Des attaquants exploitent cette dépendance en se faisant passer pour des employés bloqués par la MFA. La rigidité technique renforce la vulnérabilité sociale.
Pourquoi ces contournements ne sont pas des erreurs humaines
Il est tentant de blâmer les utilisateurs, mais ce serait une erreur d’analyse. Dans une lecture systémique, le contournement est une réponse rationnelle à une contrainte perçue comme excessive.
Les individus cherchent à préserver leur efficacité, réduire la complexité, éviter les interruptions. La sécurité n’est pas sacrifiée par négligence, elle l’est au profit de la fluidité parce que le système récompense la fluidité et punit la lenteur.
C’est la même logique que les commerciaux qui continuent à signer des deals PME alors que la stratégie dit « grands comptes ». Ils ne s’opposent pas à la direction, ils répondent à la régulation dominante. Ici, la régulation dominante est la productivité.
Les vulnérabilités nouvelles créées par la solution
Une MFA plus forte sur le papier peut être plus fragile dans le monde réel si elle augmente le nombre de situations où l’utilisateur doit improviser. Quatre mécanismes précis méritent l’attention du dirigeant.
Si l’authentification se fait via notifications « Valider/Refuser », un attaquant peut bombarder l’utilisateur jusqu’à obtenir une validation par lassitude. Plus les notifications sont fréquentes, plus le cerveau traite l’alerte comme du bruit. C’est le cas Uber.
Quand la MFA bloque l’accès, l’entreprise ouvre des voies de secours (hotline, reset par email, procédures d’urgence). Si ces voies sont mal contrôlées, elles deviennent le chemin le plus simple pour l’attaquant. La brèche n’est pas le mécanisme MFA, c’est la procédure de contournement officielle.
Téléphone perdu, batterie à plat, application cassée, changement de numéro. Ces incidents arrivent tous les jours. Si la MFA n’intègre pas une stratégie de continuité, les utilisateurs créent la leur : captures d’écran de codes, sauvegardes bricolées, partage de token.
Imposer une MFA sur téléphone personnel sans cadre clair crée du ressentiment et des bricolages. La sécurité technique se heurte à la sécurité psychologique : « on m’impose un outil, je reprends la main comme je peux ».
La décision que le dirigeant doit prendre, et non le DSI
La sécurité ne doit pas être laissée uniquement aux équipes techniques. C’est une décision d’arbitrage organisationnel qui implique trois variables que seul le dirigeant peut pondérer : le niveau de risque acceptable (quelle exposition est tolérable ?), l’impact sur la productivité (quel coût humain est justifiable ?), et la cohérence culturelle (ce dispositif est-il compatible avec la manière dont cette organisation fonctionne réellement ?).
Une décision purement technique sur ces trois variables produit un déséquilibre organisationnel. Le DSI optimise la sécurité. Le dirigeant arbitre le système.
Grille de décision dirigeant : Six principes pour une sécurité viable
P 01
Gradation selon la criticité réelle
Tous les accès ne nécessitent pas la même rigueur. Segmenter selon la criticité des données, l’exposition externe et le rôle utilisateur. La proportionnalité réduit la friction et donc le contournement.
P 02
Cohérence des méthodes
Unifier les solutions MFA autant que possible. Moins de diversité d’outils = moins de charge cognitive = moins de comportements de contournement.
P 03
Sécuriser la récupération plus que l’accès
La procédure « j’ai perdu mon téléphone » doit être plus difficile à falsifier que l’authentification normale. C’est là que se trouvent les vraies brèches, et non dans le mécanisme MFA lui-même.
P 04
Mesurer les contournements comme indicateur systémique
Observer comptes génériques, partages suspects, comportements anormaux, pas pour sanctionner, mais pour comprendre les frictions. Si les utilisateurs contournent massivement, c’est un signal que la décision a été prise au mauvais niveau.
P 05
Expliquer, pas imposer
La sécurité acceptée est plus robuste que la sécurité subie. Partager les risques réels, les exemples d’attaques, les conséquences concrètes. La compréhension augmente l’adhésion et réduit mécaniquement les comportements de contournement.
P 06
Boucle d’ajustement continue
La sécurité doit être testée en conditions réelles, pas seulement auditée sur le papier. Un dispositif qui produit massivement du contournement n’est pas un problème de discipline. C’est un problème de conception décisionnelle à revoir.
La sécurité est un problème de décision systémique, pas un problème technique
L’attaquant qui a pénétré les systèmes d’Uber en 2022 n’a pas cassé la MFA. Il a exploité la décision qui avait rendu la MFA insupportable pour les utilisateurs. La vulnérabilité n’était pas dans le code mais dans l’arbitrage.
Dans un système humain, toute contrainte produit une adaptation. Si cette adaptation prend la forme de contournements invisibles, la sécurité formelle augmente pendant que la vulnérabilité réelle se déplace. C’est le même mécanisme que Nokia, que les réformes qui échouent, que les repositionnements commerciaux qui n’atterrissent pas.
La question stratégique n’est pas d’identifier comment ajouter une couche supplémentaire mais comment concevoir une sécurité suffisamment robuste pour décourager l’attaque et suffisamment fluide pour éviter le contournement. C’est dans cet équilibre que réside la véritable résilience numérique.
Ce que vous venez de lire n’est pas un cas isolé. C’est une structure qui se répète. Tant que vous intervenez au mauvais endroit, rien ne change, même avec de bonnes décisions.
Noos identifie en quelques minutes le point précis où le système se bloque, et ce qui maintient le problème en place.
Foire aux questions
Références
- CISA & FBI (2022) – Alert AA22-264A : MFA Fatigue Attacks – Cybersecurity and Infrastructure Security Agency (analyse officielle de l’attaque Uber 2022, mécanismes de MFA fatigue, recommandations)
- Anderson, R. (2020) – Security Engineering : A Guide to Building Dependable Distributed Systems – Wiley
- Sasse, M.A. & Flechais, I. (2005) – Usable Security : Why Do We Need It? How Do We Get It ? – O’Reilly
- Crozier, M. & Friedberg, E. (1977) – L’acteur et le système – Éditions du Seuil
- Dupuy, F. (2011) – Sociologie du changement – Dunod
- Reason, J. (1990) – Human Error – Cambridge University Press (erreurs systémiques vs erreurs individuelles, facteur humain dans les défaillances de sécurité)
- Hadnagy, C. (2011) – Social Engineering : The Art of Human Hacking – Wiley
- Mitnick, K. & Simon, W. (2002) – The Art of Deception – Wiley
- ANSSI (2022) – Recommandations relatives à l’authentification multi-facteur et aux mots de passe – Agence Nationale de la Sécurité des Systèmes d’Information