Un zero-day ne casse pas un mot de passe : il rend le mot de passe hors sujet. Soit il contourne la vérification, soit il donne accès à la base de secrets d'un seul coup. La question à poser n'est donc pas « nos mots de passe résisteraient-ils ? » mais « que vaut encore notre parc de secrets une fois le correctif appliqué ? ». La réponse tient en un mot : la rémanence, et c'est là que le mot de passe coûte le plus cher.
Trois familles de failles, trois effets distincts
Toutes les vulnérabilités inédites n'ont pas le même rapport à l'authentification.
- Le contournement d'authentification. La faille permet d'obtenir une session valide sans présenter de facteur, par exemple via une erreur de logique dans un point d'accès ou une gestion défectueuse de jeton. La qualité des secrets est totalement indifférente.
- L'exécution de code sur un composant d'identité. Passerelle d'accès distant, annuaire, fournisseur d'identité : l'attaquant s'installe là où transitent ou reposent les secrets. Il récupère alors des empreintes, parfois des valeurs en clair au moment de la saisie, et souvent des jetons de session en mémoire.
- La compromission d'un poste utilisateur. Un logiciel dérobeur d'informations exploite une faille du navigateur ou d'un composant local, puis extrait les identifiants enregistrés et les cookies de session. Le secret n'est pas attaqué, il est ramassé.
Dans les trois cas, l'authentification n'a pas échoué à sa fonction : elle a été court-circuitée.
Le vrai coût du mot de passe : ce qui reste après le correctif
C'est le point que les plans de réponse sous-estiment. Un correctif ferme la faille ; il ne dévalue pas les secrets déjà exfiltrés. Un mot de passe est un secret statique : sa valeur pour l'attaquant survit à la correction, et elle survit même au périmètre concerné, puisque le même secret est très probablement réutilisé ailleurs.
Concrètement, un incident de ce type impose une réinitialisation de masse — l'opération la plus coûteuse et la plus perturbatrice d'une réponse à incident, avec ses effets en cascade sur le service d'assistance, les comptes de service et les intégrations. Et elle laisse un résidu : les utilisateurs qui avaient réutilisé leur mot de passe sur des services personnels restent exposés, sans que l'organisation puisse y faire quoi que ce soit.
| Type de zero-day | Le mot de passe protège-t-il ? | Ce qui limite l'impact | Résidu après correctif |
|---|---|---|---|
| Contournement d'authentification | Non | Cloisonnement, sessions courtes | Faible si aucun secret exposé |
| Exécution de code sur l'IdP | Non | Hachage lent et salé, cloisonnement | Élevé : secrets et jetons compromis |
| Fuite de la base d'empreintes | Partiellement | Entropie, fonction de dérivation lente | Élevé : cassage hors ligne à froid |
| Dérobeur d'informations sur le poste | Non | Durée de vie des sessions, liaison d'appareil | Élevé : secrets et cookies |
| Faille d'un client lourd métier | Non | Segmentation, moindre privilège | Variable |
Ce qui réduit réellement l'exposition
Aucune méthode d'authentification n'empêche l'exploitation d'une vulnérabilité inédite. En revanche, le choix du facteur détermine ce qu'il reste à ramasser pour l'attaquant, et donc le coût de la remise en état.
Quatre orientations comptent :
- Ne pas conserver de valeur réutilisable. Ce qui n'existe pas ne peut être exfiltré. C'est le raisonnement de fond derrière les approches passwordless et IDless : moins de secrets détenus centralement, moins de valeur exposée par une intrusion.
- Réduire la durée de vie et la portée des sessions. Puisque le butin le plus fréquent est un jeton, sa durée de validité définit directement la fenêtre d'exploitation.
- Faire varier ce qui est vérifié. Le polymorphisme fonctionnel et le principe de Moving Target Defense empêchent qu'une observation, même privilégiée, reste exploitable ensuite : ce qui a été capturé à un instant donné n'est plus valide au suivant.
- Exiger une validation d'intention sur les opérations sensibles. Une session obtenue par une faille ne suffit alors plus à agir : il faut une preuve humaine au moment de l'action, ce que l'exploitation d'une vulnérabilité ne fournit pas.
Ces propriétés sont celles du 4e facteur cognitif. Elles ne préviennent pas la faille — rien ne le fait — mais elles transforment un incident aux conséquences durables en incident borné dans le temps.
FAQ
Une MFA protège-t-elle contre un zero-day ?
Contre le contournement d'authentification, non : la faille précède la vérification. Contre les suites de l'incident, oui, à condition que le second facteur ne soit pas lui-même stocké côté serveur sous une forme rejouable et que les opérations sensibles exigent une validation distincte.
Le hachage des mots de passe rend-il une fuite inoffensive ?
Il en retarde l'exploitation, de façon très variable. Une fonction de dérivation lente avec sel impose un coût réel, mais les secrets faibles ou dérivés d'un mot courant tombent rapidement. Une fuite d'empreintes doit être traitée comme une fuite de secrets, pas comme un incident mineur.
Faut-il réinitialiser tous les mots de passe après une intrusion sur l'annuaire ?
Oui, en incluant les comptes de service, les clés d'interface et les secrets d'intégration, qui sont régulièrement oubliés. Il faut aussi révoquer les sessions et les jetons, faute de quoi la réinitialisation ne délogera pas l'attaquant.
Comment limiter la casse quand la faille touche un composant que l'on ne maîtrise pas ?
Par le cloisonnement et par la réduction de la valeur exposée : moindre privilège, séparation des environnements, sessions courtes, et surtout un mécanisme d'authentification qui ne laisse pas de secret durable à récupérer sur le composant vulnérable.
Aller plus loin : le pilier authentification cognitive · polymorphisme face aux zero-day · mot de passe et brute force · vol de session et token theft