Dashlane : brute-force 2FA, des coffres chiffrés téléchargés

Une attaque brute-force contourne la 2FA et exfiltre des coffres chiffrés

Le dimanche 31 mai 2026, un acteur malveillant non identifié a lancé une attaque brute-force automatisée ciblant les comptes utilisateurs du gestionnaire de mots de passe Dashlane. L'information a été confirmée le 1er juin 2026 via un avis de sécurité publié directement sur le portail support de la société, et largement relayé par BleepingComputer, SecurityWeek, The Hacker News et The Next Web.

L'objectif de l'attaquant était de contourner les protections d'authentification à deux facteurs (2FA) afin d'enregistrer de nouveaux appareils sur des comptes existants — condition nécessaire pour pouvoir ensuite télécharger les coffres des victimes. Le vecteur ciblé est le code TOTP (Time-based One-Time Password), cette séquence numérique à 6 chiffres générée par des applications comme Google Authenticator ou Authy et qui expire toutes les 30 secondes. L'attaquant a utilisé des logiciels automatisés pour soumettre en rafale toutes les combinaisons numériques possibles dans l'espoir d'en deviner une correcte avant expiration.

La fenêtre d'opportunité est théoriquement très réduite : un code TOTP expire toutes les 30 secondes et les combinaisons possibles pour 6 chiffres sont au nombre de 1 000 000. Pour brute-forcer statistiquement un code, il faut être capable de soumettre un très grand nombre de tentatives par seconde. Cette vitesse est difficile à atteindre si les serveurs implémentent un rate limiting strict — une limitation du nombre de requêtes par compte et par unité de temps. L'incident suggère que les mécanismes de rate limiting de Dashlane, ou leur fenêtre temporelle de détection, n'ont pas été suffisamment robustes pour contrer une attaque distribuée à haut débit, possiblement orchestrée depuis un botnet pour contourner les limitations par adresse IP.

Selon l'avis de sécurité officiel, les contrôles automatiques de la plateforme ont fini par détecter le volume anormal de tentatives et ont verrouillé les comptes ciblés. Cependant, pour un sous-ensemble restreint — moins de 20 comptes personnels — les attaquants ont réussi à franchir la barrière 2FA, enregistrer un nouvel appareil, et télécharger une copie du coffre chiffré correspondant. Dashlane précise avoir notifié directement chacun des utilisateurs concernés et que l'accès aux comptes verrouillés a depuis été restauré.

Le contenu exfiltré — les coffres — est chiffré selon l'architecture zero-knowledge de Dashlane. Le mot de passe maître (Master Password) n'est jamais transmis aux serveurs de Dashlane : il reste exclusivement côté client et sert à chiffrer et déchiffrer le coffre localement. Les données que les attaquants ont téléchargées sont donc cryptographiquement opaques sans connaissance du mot de passe maître. Dashlane souligne que même en cas de tentative de craquage hors ligne prolongée, les chances de succès restent statistiquement infimes pour un mot de passe fort.

La nuance critique est la suivante : si l'un des utilisateurs touchés utilisait un mot de passe maître faible, court ou réutilisé depuis une autre fuite de données, son coffre peut être compromis via une attaque par dictionnaire ou credential stuffing sur la version chiffrée. Ce scénario, bien que plus coûteux en ressources computationnelles, reste réaliste — d'autant plus que des bases de données massives de mots de passe courants sont disponibles sur les marchés clandestins et que les GPU modernes permettent des dizaines de milliards d'essais par seconde contre des fonctions de hachage insuffisamment renforcées.

L'investigation de Dashlane n'a trouvé aucune preuve de compromission des systèmes internes de l'entreprise. L'attaque a opéré au niveau applicatif, en exploitant la surface d'exposition externe des comptes utilisateurs, et non via une intrusion dans l'infrastructure backend. La société a renforcé ses mécanismes de détection d'anomalies à l'issue de l'incident pour prévenir une récurrence.

Les recommandations formulées par Dashlane à ses utilisateurs sont claires : vérifier la liste des appareils enregistrés sur le compte et supprimer tout appareil non reconnu, activer la 2FA si ce n'est pas encore fait, choisir un mot de passe maître long et unique — idéalement une phrase de passe de plusieurs mots aléatoires d'au moins 16 caractères — et envisager de passer à une méthode d'authentification plus robuste comme une clé matérielle FIDO2/WebAuthn si le plan souscrit le permet.

Les limites du TOTP face aux attaques modernes : un débat relancé

L'incident Dashlane relance un débat de fond dans la communauté de la sécurité : le TOTP à 6 chiffres, bien qu'infiniment supérieur à une absence de 2FA, constitue-t-il une défense suffisante pour des cibles à haute valeur comme les gestionnaires de mots de passe ? La réponse technique est nuancée. En théorie, un rate limiting correctement implémenté — par exemple 5 tentatives par compte toutes les 30 secondes avec blocage progressif — rend la brute-force d'un TOTP statistiquement impossible. En pratique, les implémentations sont rarement parfaites, et les attaques distribuées depuis des milliers d'adresses IP différentes peuvent contourner des limitations basées uniquement sur la source IP.

Le précédent LastPass de 2022 avait déjà illustré les conséquences catastrophiques d'un vol de coffres chiffrés, même sans accès immédiat aux mots de passe maîtres : des mois plus tard, des milliers de coffres avaient été partiellement craqués via des attaques GPU sur des hashes insuffisamment renforcés avec des itérations PBKDF2 trop faibles. La leçon est que la sécurité d'un gestionnaire de mots de passe ne se résume pas au chiffrement du coffre — elle passe aussi par des itérations suffisantes des fonctions de dérivation de clé (KDF) comme PBKDF2, bcrypt ou Argon2, et par une politique agressive de mots de passe maîtres forts.

Pour les entreprises qui s'interrogent sur le bon niveau de protection de leurs outils de gestion de secrets, l'incident Dashlane illustre plusieurs impératifs pratiques. Les gestionnaires de mots de passe d'entreprise doivent imposer l'utilisation de clés matérielles FIDO2 plutôt que du TOTP logiciel pour les accès administrateurs et les comptes à privilèges. Les politiques de mot de passe maître doivent être contrôlées et auditées — une longueur minimale de 16 caractères avec entropie élevée devrait être obligatoire. Les entreprises utilisant un gestionnaire de mots de passe cloud doivent surveiller les alertes d'enregistrement de nouveaux appareils en temps réel via leurs outils SIEM.

L'incident reste limité dans ses conséquences immédiates : moins de 20 coffres téléchargés, des données protégées par un chiffrement fort, aucune compromission de l'infrastructure de Dashlane. Mais il constitue un rappel que les gestionnaires de mots de passe — outils de confiance centrale dans toute architecture Zero Trust — sont eux-mêmes des cibles de choix, et que leur sécurité dépend autant de la solidité du produit que des comportements de leurs utilisateurs.

Ce qu'il faut retenir

• Des attaquants ont brute-forcé les codes TOTP de Dashlane le 31 mai 2026, enregistrant de nouveaux appareils sur moins de 20 comptes et téléchargeant leurs coffres chiffrés.
• Les coffres restent protégés par le mot de passe maître non transmis aux serveurs, mais les utilisateurs avec un Master Password faible sont exposés à un craquage hors ligne par GPU.
• Action immédiate recommandée : vérifier les appareils enregistrés, révoquer tout appareil inconnu, et migrer vers une clé FIDO2/WebAuthn pour la 2FA si possible.