Introduction
Le 2 juin 2026, Dashlane a publié un avis sobre : une vingtaine de coffres-forts chiffrés dérobés lors d'une attaque survenue deux jours plus tôt. Le périmètre est restreint, mais l'avis laisse sans réponse les questions que tout responsable informatique se pose en premier. Comment une attaque par force brute a-t-elle abouti sur un service protégé par une authentification à deux facteurs ? Quelles mesures correctives ont été déployées ? L'opacité d'un éditeur en temps de crise est souvent aussi révélatrice que l'incident lui-même.
La mécanique de l'attaque
Le 31 mai 2026, un acteur malveillant externe a ciblé les codes TOTP du second facteur d'authentification de certains comptes Dashlane. Ces codes à six chiffres ne présentent qu'un million de combinaisons par fenêtre de trente secondes — une contrainte exploitable via des outils automatisés qui soumettent chaque combinaison avant expiration du code.
En enregistrant de nouveaux appareils sur les comptes ciblés, les attaquants ont pu déclencher la synchronisation et télécharger les coffres de moins d'une vingtaine d'utilisateurs du plan personnel. Les systèmes de Dashlane ont fini par verrouiller automatiquement les comptes visés, mais pas avant que les données soient copiées. L'éditeur précise n'avoir aucune preuve de compromission de ses propres infrastructures.
Ce que l'avis ne dit pas
Trois questions restent sans réponse dans le communiqué de Dashlane.
Premièrement, pourquoi le rate limiting n'a-t-il pas bloqué l'attaque ? Toute protection 2FA sérieuse doit limiter les tentatives par compte et par unité de temps. Soit ce mécanisme était insuffisant, soit il a été contourné — l'éditeur n'explique ni l'un ni l'autre. Deuxièmement, quelles mesures correctives ont été appliquées et à quelle date ? L'avis évoque des « actions » sans les détailler. Troisièmement, comment ces comptes ont-ils été sélectionnés ? Un ciblage opportuniste et un ciblage précis n'impliquent pas le même niveau de risque résiduel.
Pour un RSSI ou un responsable IT, ces lacunes rendent impossible toute évaluation du risque restant et toute réponse proportionnée à l'incident.
Le risque réel : le maillon faible reste le mot de passe maître
Les coffres dérobés sont chiffrés selon une architecture zero-knowledge : Dashlane ne stocke jamais les mots de passe maîtres. Sans ce mot de passe, les données restent en théorie illisibles.
En pratique, les attaquants disposent de copies hors ligne qu'ils peuvent tenter de déchiffrer sans contrainte de temps ni de tentatives. Un mot de passe maître court, réutilisé ou construit sur un schéma prévisible devient alors la seule ligne de défense restante. Dashlane le reconnaît lui-même dans son avis : les utilisateurs dont le mot de passe maître est faible sont exposés à un risque accru de déchiffrement différé.
Ce que cet incident devrait changer dans votre politique des accès
Quatre réflexes méritent d'être tirés de cet incident, quelle que soit la solution de gestion des mots de passe en place dans votre organisation :
- Privilégier les clés de sécurité matérielles (FIDO2/passkeys) plutôt que les codes TOTP pour les comptes critiques : elles sont immunisées contre la force brute sur codes temporels, car chaque réponse est liée à l'origine de la requête.
- Imposer une complexité stricte du mot de passe maître dans les déploiements entreprise et en vérifier régulièrement l'application via une politique documentée.
- Auditer la politique de notification d'incident de vos fournisseurs SaaS critiques avant toute crise : un éditeur incapable de décrire précisément un vecteur d'attaque après coup est un indicateur de maturité sécurité insuffisante.
- Traiter les avis de sécurité éditeurs comme des alertes opérationnelles, au même titre que vos propres remontées d'incident — pas comme des communications à archiver.
L'incident Dashlane reste limité en périmètre. Mais il rappelle une vérité inconfortable : la confiance accordée à un outil de sécurité doit reposer autant sur la transparence de son éditeur face à l'adversité que sur ses fonctionnalités. Et cela, aucune fiche produit ne le garantit.