Connexion Premium

Zero Knowledge : une étude pointe les carences de Bitwarden, LastPass et Dashlane

Zero virgule cinq Knowledge

Zero Knowledge : une étude pointe les carences de Bitwarden, LastPass et Dashlane

Une étude réalisée par des chercheurs de l’École polytechnique fédérale de Zurich révèle que Bitwarden, LastPass et Dashlane pourraient, dans des conditions exceptionnelles, permettre la divulgation du mot de passe principal de leurs utilisateurs, en dépit de leur promesse relative au chiffrement « Zero Knowledge ». Les trois services indiquent avoir déjà implémenté les corrections nécessaires.

Le 17 février à 17h13

Devenus incontournables dans le quotidien de millions d’internautes, les gestionnaires de mot de passe opérés dans le cloud offrent-ils les garanties de sécurité nécessaires et suffisantes ? Une étude menée sous l’égide de l’École polytechnique fédérale de Zurich (ETH Zurich) conclut que trois services parmi les plus populaires du secteur présentaient des vulnérabilités susceptibles de conduire à la divulgation ou à la modification du mot de passe principal du compte de l’utilisateur.

Au cours de leurs travaux, les chercheurs ont exploité un scénario possible, mais très hypothétique : celui d’une prise de contrôle du serveur chargé des interactions avec l’utilisateur final. Dans ce contexte exceptionnel, ils indiquent avoir réussi à mener douze attaques différentes conduisant à une compromission du mot de passe chez Bitwarden, contre sept pour LastPass et six chez Dashlane. Les chercheurs ne remettent pas en cause la sécurité des chiffrements mis en œuvre : d’après leurs observations, c’est principalement au niveau des mécanismes chargés de faciliter la vie des utilisateurs que se situent les vulnérabilités.

La promesse du Zero Knowledge

Les gestionnaires de mot de passe en ligne invoquent en général le concept de Zero Knowledge (littéralement, « aucune connaissance ») pour rassurer leurs utilisateurs quant à la sécurité de leurs données. Bien qu’il n’obéisse pas à une définition ou à des conditions techniques de mise en œuvre strictes, il suppose que le serveur qui stocke les mots de passe est littéralement incapable d’en connaître le contenu, parce que ce contenu est chiffré et que seul l’utilisateur final dispose de la clé privée indispensable à son déchiffrement.

« Techniquement, Dashlane ne possède pas d’autre clé, mais nous avons bâti un mécanisme de chiffrement qui garantit que votre coffre-fort est sécurisé avec votre clé et que les données du coffre-fort ne sont accessibles que par vous, le propriétaire. C’est pourquoi toutes les opérations sensibles de Dashlane, le chiffrement et le déchiffrement de votre coffre-fort en l’occurrence, sont effectuées localement sur votre appareil. Cela garantit que nous ne les voyons pas sur nos serveurs. », illustre par exemple Dashlane.

Cette promesse tient-elle toujours si le serveur qui héberge les mots de passe est compromis ? L’étude complète, annoncée et publiée par l’ETH Zurich (PDF), répond par la négative. Au cours de leurs travaux, les chercheurs indiquent en effet avoir mené avec succès quatre types d’attaques, exploitant respectivement les fonctionnalités de séquestre utilisées pour la récupération de compte et la connexion unifiée (SSO), les manquements du coffre-fort en matière d’intégrité, les fonctionnalités de partage et les outils dédiés à la rétrocompatibilité.

Une surface d’attaque augmentée par la complexité du code

Les auteurs précisent avoir sélectionné Bitwarden, LastPass et Dashlane à la fois parce que ces derniers peuvent être considérés comme représentatifs du secteur (par leur ancienneté et leur parc de clients, estimé à 60 millions d’utilisateurs cumulés, ou 23 % de parts de marché) et parce que le code de leurs clients logiciels est ouvert (totalement pour Bitwarden, partiellement pour les deux autres), contrairement à celui des solutions d’Apple ou de Google, très populaires puisque intégrées à leurs environnements mobiles.

Au total, 25 attaques ont donc ont été menées avec succès sur l’ensemble des services examinés. « Nous avons été surpris par la gravité des failles de sécurité », commente Kenneth Paterson, l’un des auteurs de l’étude, selon qui la découverte est d’autant plus criante que les gestionnaires de mots de passe constituent, par essence, une cible à très forte valeur perçue pour des attaquants. Les auteurs remarquent par ailleurs que si les conditions de test sont particulières (serveur malveillant), leurs attaques sont réalisées par le truchement d’interactions « normales » de l’utilisateur final avec le service.

Dans la discussion qui suit l’exposé de leurs attaques, ils remarquent que les gestionnaires de mot de passe sont tiraillés entre deux exigences contradictoires que sont la sécurité et le niveau de service fonctionnel rendu à l’utilisateur, qui s’attend à pouvoir récupérer son mot de passe en cas de perte, consulter son gestionnaire sur tous les écrans, ou disposer de fioritures telles que la création d’accès partagés.

« Après un examen plus approfondi, nous avons constaté que les gestionnaires de mots de passe sont loin d’être simples : ils ont évolué pour inclure des protocoles complexes pour la synchronisation, la récupération et la rotation des clés, le partage d’éléments chiffrés et la migration entre différentes primitives cryptographiques [les briques qui fournissent les fonctions de base du chiffrement, ndlr] », remarquent les auteurs. C’est, selon eux, cette complexité accrue qui augmenterait la surface d’attaque potentielle.

Les gestionnaires de mots de passe accusent réception

Avertis en amont de la publication de l’étude, les trois éditeurs de services concernés ont accusé réception de ces découvertes. « Tous les problèmes identifiés dans le rapport ont été traités », promet Bitwarden qui détaille les réponses apportées dans un rapport de transparence dédié (PDF). Trois ne seront cependant pas corrigés, parce que le remède compromettrait certaines fonctionnalités du service, indique tout de même l’éditeur. Qui profite de l’occasion pour « réaffirmer que Bitwarden n’a jamais subi de violation de données ».

Dashlane salue également ce travail de recherche, qualifié d’exercice utile, et précise avoir apporté tous les correctifs jugés nécessaires dans sa version 6.2544.1 publiée le 5 novembre dernier. Le service en profite pour souligner que les fonctionnalités de partage (basées sur une clé publique) et les mécaniques de synchronisation basées sur l’échange de transactions chiffrées sont des difficultés intrinsèques au service rendu.

« Cette recherche met en lumière plusieurs enseignements :
– Maintenir les méthodes cryptographiques à jour est essentiel pour la sécurité, mais cela introduit une complexité qui doit être gérée avec soin.
– L’authentification de clé publique à grande échelle est un défi connu que notre secteur doit relever.
 »

Même son de cloche du côté de LastPass, qui indique avoir déjà corrigé l’une des vulnérabilités mises au jour par l’ETH, et ajoute plancher sur la sécurisation des parcours de réinitialisation et de partage, ainsi que sur l’amélioration des mécanismes dédiés au contrôle d’intégrité.

Une démarche à laquelle adhèrent tacitement les chercheurs :

« Les vulnérabilités que nous décrivons sont nombreuses, mais pour la plupart mineures sur le plan technique. Pourtant, elles n’avaient apparemment pas été découvertes auparavant, malgré plus d’une décennie de recherche universitaire sur les gestionnaires de mots de passe et l’existence de multiples audits des trois produits que nous avons étudiés. Ceci motive la poursuite des travaux, tant sur le plan théorique que pratique. »

Commentaires (37)

votre avatar
Est-ce que le meilleur ça reste pas Keepass ?
votre avatar
On parle ici de solution permettant un partage de coffre entre clients, les seules implémentations présentées (existantes ?) passant par un stockage unique centralisé.
Ce n'est pas le fonctionnement de KeePass, et la problématique de la modification concurrente d'un même coffre n'est alors pas adressée : outil adapté à un autre cas d'usage.

Dans l'article proposant la prise en main de Vaultwarden, j'ai d'ailleurs aussi souligné un autre souci de fonctionnement de Bitwarden, qui n'est pas une faille technique, mais plutôt un choix (problème ?) de conception : l'impossibilité de conserver une copie/accès local à un coffre, hors situation temporaire.

Je suis moi aussi à la recherche d'une solution permettant un partage/une synchronisation de coffre, mais qui permettrait aussi de manière pérenne un accès à une copie local d'un coffre qui ne serait synchronisé avec une "source de vérité" qu'au bon vouloir de l'utilisateur : la garantie de cohérence entre les coffres des clients n'est finalement nécessaire que lorsque l'utilisateur souhaite/peut maintenir une connexion à celle-ci.
Mon cas d'usage permettrait que le coffre stocke des identifiants permettant de restaurer le(s) service(s) de stockage distant, sans souffrir de dépendance circulaire, sans jongler entre différents coffres, et donc sans à avoir à recourir à de la redondance de sauvegarde de plusieurs d'entre-eux.

À ce jour, je reste sur ma faim.
votre avatar
Concernant Keepassxc, il me semble qu'une versions récente détecte les modifications du fichier quand le coffret est ouvert, afin de permettre un fonctionnement avec un dossier synchronisé comme par exemple nexcloud. A vérifier donc
votre avatar
Non ça ne marche pas comme ça, ça va marcher sur un partage réseau (hors mode déconnecté), mais tout ce qui est stocké dans le cloud se télescopera à moment donné.

Avec keepass (pas keepassxc il ne me semble pas qu'il le fasse) il y a une solution en faisant une double synchro pour éviter ce télescopage mais ce n'est pas géré nativement.
https://keepass.info/help/kb/trigger_examples.html#dbsync

Il ne faut pas oublier que toute synchro avec cloud tu as au finale 3 copies du même fichier, 1 sur chaque pc (2 donc) + la 3ème sur le serveur, et le temps que l'info de modification remonte sur le serveur, le fichier peut être modifié de l'autre côté (on est très loin de l'instantané)


Ta solution est acceptable s'il n'y a jamais d'usage simultanée (genre une même personne avec son portefeuille et qui travail seule sur plusieurs appareil jamais en même temps là oui ça marche parfaitement.
votre avatar
dsl j'ai répondu plus bas sans avoir lu ton comm' c'est de ça dont je parlais.
Le plugin gère un timestamp par entrée, du coup en usage individuel c'est relativement fiable. Tu ne vas pas pouvoir mettre à jour en même temps la même entrée sur deux périphériques.
Sans ce plugin, le verrou se gère sur le fichier et tout enregistrement à deux endroits génère une nouvelle version de conflit.
votre avatar
passwordstore ?

Bon , ok, pas très facile à utiliser pour qui n'est pas développeur (vu que basé sur gpg & git)
votre avatar
Hum, pour la partie :
Dans l'article proposant la prise en main de Vaultwarden, j'ai d'ailleurs aussi souligné un autre souci de fonctionnement de Bitwarden, qui n'est pas une faille technique, mais plutôt un choix (problème ?) de conception : l'impossibilité de conserver une copie/accès local à un coffre, hors situation temporaire.
En utilisant une extension ou l'app, même déconnecté du net, ca marche !
J'utilise pas mal mon tel en mode avion, et Bitwarden fonctionne parfaitement, même le TOTP !
votre avatar
Je t'encourage à aller lire la documentation que j'ai liée dans le commentaire originel, plutôt que de te fier à une expérience personnelle, souvent partielle.
Il y est indiqué dans quelles conditions ton coffre hors-ligne peut être accessible, et le cas échant pour quelle durée.
votre avatar
J'utilise Keepass exactement comme la solution que tu recherche. Keepass a son fichier en local (PC et mobile). J'ai une copie sur un serveur WebDav, et je synchronise les "clients" avec le "serveurs" comme je le veux, avec la fonction intégrée de Keepass, qui est parfaitement capable de fusionner des modifs sur les deux fichiers. Je peux ajouter une entrée A sur le mobile une B sur le PC, puis synchroniser via le serveur et à la fin j'aurai les les entrées A et B partout. Le "serveur" ne sert que de pont. Les "clients" restent entièrement autonomes (c'est un point essentiel pour moi, qui exclu de facto BitWarden). Tu peux aussi ne pas passer par un serveur WebDav, mais une clef USB ou un partage Samba. Note toutefois que ce cas ne marche qu'avec le KeePass "original" (KeepassXC ne propose pas la synchro/fusion distante). Et j'utilise keepass2android sur mobile.
votre avatar
J'ai exactement la même utilisation, et c'est aussi pour cela que je n'utilise pas KeepassXC, car si j'ai bien compris, la synchro est faite "au niveau fichier" et pas dans la base elle meme (qui du coup conserve un historique, bien pratique en cas de modif non prisen en compte par le site...). Mais j'avoues ne pas avoir essayer 2 modifs (sur 2 PC clients) en simultané... Et je ne sais pas si on peux (mais probablement pas) avoir plusieurs utilisateurs distincts.
votre avatar
Depuis le nombre d'années que je l'utilise, jamais eu de problème avec les modifs simultanées. Je suppose que ça s’appuie sur l'historique pour gérer cela intelligemment.
Il n'y a de multi-utilisateurs. C'est impossible vu que ce n'est qu'un fichier avec un process local. Pour cela, il faut faire un fichier commun à part, et utiliser de déverrouillage automatique d'autre fichier de KeePass. En gros, ton fichier perso contient le mdp du fichier commun qui est utilisé pour ouvrir, en plus, le fichier commun.
votre avatar
J'ai un client web (très rustre) de lecture pour keepass: cela permet à la fois de partager avec l'équipe, et en plus me logue qui a demandé quel MDP quand.
Je suis en train d'intégrer aussi directement le keepass dans mremoteng pour que le MDP ne soit même plus sorti de keepass.
votre avatar
Comme gestionnaires de mots de passe centralisés, il y a Psono (open source) ou Pleasant Password (propriétaire, client dérivé de KeePass), par exemple.
votre avatar
Les clients (applis, extension ..) ont une copie de la base en local du coffre, fonctionnel aussi longtemps que tu le souhaites et tu peux l'enrichir, importer et exporter sans serveur donc ça fonctionne aussi en local.
votre avatar
Ce n'est pas le fonctionnement de KeePass, et la problématique de la modification concurrente d'un même coffre n'est alors pas adressée : outil adapté à un autre cas d'usage.
Il y'a un plugin (documenté sur le site officiel) pour synchroniser correctement Keepass sur un cloud / NAS central : chaque entrée a un timestamp, et à la sauvegarde le plugin récupère la base centrale et fusionne les timestamps les plus récents de chaque entrée pour créer la nouvelle version.

Usage ressenti :

  • Tu peux mettre à jour les données de ton coffre de n'importe quel périphérique, et ça arrive nativement partout (comme un cloud normal donc)


Point négatif :

  • le plugin ne s'exécute qu'à l'ouverture / enregistrement : donc il faut penser à fermer sa base localement pour quelle récupère les mise à jour.

  • keepass déconne (il faut attendre un timeout) quand tu n'as pas de réseau

  • c'est un plugin à bricoler sur chaque install de keepass (sur PC c'est relativement simple sur mobile c'est déjà autre chose)

  • les conflits restent possible si tu n'as pas d'accès au réseau quand tu changes un mot de passe, ou que tu as laissé ouvert une autre version de ton coffre en faisant une modif ailleurs.

votre avatar
C'est la question que je me pose aussi.

Même si je ne remets pas en cause le côté pratique de la chose avec ces services, surtout d'avoir accès aux infos de partout avec synchro automatique et la gestion accès en cas de partage, j'ai toujours eu du mal avec le principe d'aller stocker mes mots de passe dans le cloud.

Mais pour un usage individuel, à moins que je sache le user/mdp de tête, j'ai finalement assez peu de cas d'usage récurrents pour lesquels ça ne peut pas attendre que je sois rentré chez moi pour accéder à mon KeePass (synchronisé entre mon NAS et appareils locaux dont le stockage est chiffré).

Reste qu'avec KeePass bien sûr les sauvegardes/synchro sont à notre charge, on ne peut pas tout avoir.

Je sais qu'il existe une version mobile mais j'avoue ne pas m'en être encore servi ...
votre avatar
C'est quoi pour toi "le cloud"?
Parce que bitwarden (vaultwarden) ça s'auto héberge aussi et ce n'est du coup pas du cloud. :D

Sinon les usages de l’intérêt de bitwarden and co par rapport à keepass en entreprise c'est de pouvoir gérer les droits par projet etc, rajouter une personne etc.

En personnel, si tu veux gérer/partager des mots de passes avec ta famille pour des gens qui ne sont pas très doué, et que tu veux pouvoir accéder à leurs services etc. Bref il y a des cas ou pouvoir accéder aux mots de passe à distance à un intéret.
(Perso je le fais pour mes parents par exemple et je peux les aider en regardant des trucs sur leurs comptes fai etc si besoin)
votre avatar
Dommage que ProtonPass n'est pas été testé.
Merci pour l'article!
votre avatar
Parce que les PDM de protonpass sont sûrement ridicules. Si d'autres devaient être testés, ce serait bien d'avoir eu Google et MS, ceux que les gens utilisent le plus.
Les auteurs précisent avoir sélectionné Bitwarden, LastPass et Dashlane à la fois parce que ces derniers peuvent être considérés comme représentatifs du secteur (par leur ancienneté et leur parc de clients, estimé à 60 millions d'utilisateurs cumulés, ou 23 % de parts de marché) et parce que le code de leurs clients logiciels est ouvert (totalement pour Bitwarden, partiellement pour les deux autres), contrairement à celui des solutions d'Apple ou de Google, très populaires puisque intégrées à leurs environnements mobiles
votre avatar
Yes, le truc c'est que l'on est que la sécurité de Google et MS est ridicule.
Ça aurait été intéressant de savoir si l'entreprise qui est beaucoup engagé sur la vie privée a aussi ce souci.

Même si d'après un ami ingénieur logiciel chez Dashlane, Protonpass est récent et n'a donc sûrement pas de code legacy à maintenir et n'a donc pas ces failles.
votre avatar
Si on suit la logique de l'article qui explique que ces problèmes viennent des fonctionnalités poussées qu'offrent ces trois acteurs et si je me souviens bien les derniers tests de Protonpass qui disaient que c'était très simple et primaire niveau fonctionnalités, j'aurais dit la même chose que ton ami.
A voir dans quelques années ou en sera Protonpass, je pense que ca a déjà bien évolué, je ne suis pas trop.

Cependant, j'aimerais bien les vrais chiffres, parce que si ces trois arrivent à 60 Millions d'utilisateurs cumulés (ce qui me semble faible) et que Proton sur son site annonce plus de 100 millions d'utilisateurs, j'ai un petit problème de cohérence :D
votre avatar
ils disent 100 millions de comptes Proton, tout le monde n'utilise pas le Pass.
Avant j'étais chez Dashlane par exemple alors que mon Protonmail a plusieurs années.
votre avatar
Du coup c'est très trompeur !
Parce que c'est sur la page de https://proton.me/fr/pass de ProtonPass qu'ils annoncent fièrement "Adopté par plus de 100 millions de particuliers et d'entreprises" juste au dessus des témoignages d'usage de ProtonPass.
votre avatar
après c'est du marketing, je pense qu'ils parlent de 100M de compte.

https://proton.me/pass/pricing#:~:text=Join%20over%20100,their%20data%20safe&text=Tried%20other%20password,one.%20Easy%20to

"Join over 100 million users who trust Proton to keep their data safe"
votre avatar
Clairement, mais la version EN est moins trompeuse :mdr:
votre avatar
Dommage qu’ils n’aient pas testé 1Password.
votre avatar
Ils l'ont fait. Ce n'est pas dans les résumés, mais il est dans l'étude : https://eprint.iacr.org/2026/058.pdf
votre avatar
Merci pour le lien. Je suis toujours sur 1password, j'envisage de passer vers Protonpass. Trop l'habitude de 1Password.
votre avatar
En tous cas, il ne faut pas changer pour un scénario si peu probable que celui-ci. Passer sur Protonpass, hormis par conviction en se disant que c'est surement mieux parce que c'est en UE, ca n'a pas vraiment d'intérêt.

La bonne pratique c'est d'utiliser un gestionnaire, avec un mot de passe fort que l'on a en tête couplé à du MFA et générer des MDP aléatoires.

Que ce soit Keepass, Protonpass, 1pass, Dashlane ou autres, ca ne change pas grand chose je pense. Si tout le monde faisait déjà ca, ce serait un bon début :ouioui:
votre avatar
Après lecture de l'article et étant donné que les vulnérabilités portent principalement sur la compromission du mot de passe principal, je me demande si la double authentification contrecarre ces scénarios.
votre avatar
Je ne pense pas, le 2FA c'est pour l'authentification si le serveur est compromis, ils n'ont pas besoin de l'authentification.
votre avatar
Oui tu as raison et j'avais globalement saisi cet état de fait mais ce n'était pas suffisant pour comprendre comment cette compromission se concrétisait.

En relisant attentivement le PDF rédigé par Bitwarden et si on prend le premier exemple, je comprends que l'attaque réunit deux facteurs :

  • un mécanisme mis en place pour connaître le mot de passe utilisateur (en l'occurrence qui va profiter d'une rotation de clé) qui servira ensuite à dériver la clé utilisateur, clé utilisée pour chiffrer et déchiffrer le coffre.

  • l'accès direct au coffre chiffré qui ne le sera plus une fois la clé utilisateur connue.



Et donc ma conclusion, c'est que cette étude, en plus de révéler des failles, permet aussi de faire prendre conscience des limites des mesures de sécurité proposées au grand public principalement.

Par exemple, je croyais de façon un peu naïve que le deuxième facteur d'authentification participait au processus de déchiffrement, mais quand on a les éléments sous les yeux, je me rends bien compte que c'est limite absurde.

Et dernière chose, je revois aussi un peu ma position sur l'affirmation à priori trop optimiste qui dit "mes données chiffrées peuvent bien se balader n'importe où car mon mot de passe est ultra-complexe" tout en ayant conscience que la robustesse d'un mot de passe n'a de valeur que si on considère le contexte de niveau technologique actuel en termes de puissance de calcul, technos en jeu etc.
votre avatar
Je suis bien d'accord, et globalement ces études, c'est que du positif pour tout le monde.
Même si dans le cas présent, ca reste un cas à l'extrême dans un scénario très peu probable.
votre avatar
pour le cas du je stocke maintenant et je déchiffre plus tard, il faut périodiquement changer ses mots de passe (pas nécessairement fréquemment) pour rendre cette méthode caduque sur les gestionnaire de mots de passe uniquement (les autres contenus seront lisibles que ce soit des conversations confidentielles ou des documents sensibles)
votre avatar
Perso, j'ai mon vaultwarden auto-hébergé sur une instance et joignable publiquement.
Login + mdp fort & double auth à 32 caractère (de mémoire)
Only le login, pas d'inscription, pas de /admin (bah oui xD )

J'ai déjà pensé à filtrer que sur base d'IP déclarée via /32 temporaire pour les terminaux (l'app bitwarden est magique et/ou l'extension ff) et de maintenir une IP de chez moi pour quand ocnnecté en wifi at home.

Mais les changements d'ip en 4/5G peuvent être nombreux selon la couverture (bof chez moi)

J'en suis arrivé à me dire, que la sync des coffres ne se feraient at home only.
Le reste du temps, le coffre serait "offline/pas à jour" mais utilisable dans 99% des cas !

Le seul cas dérangeant, c'est le moment si il y a un changement sur un item (on a du share de collection !)
Mais le reste : add/del et même modif locale donneront à une sync ultérieure.

Du coup, je me dis pour réduire à 0.1% la surface d'attaque publique, why not.
Par contre, reste les devices faillibles pour remonter des extensions/app aux datas :/
votre avatar
Les applications comme Heylogin qui n'ont pas de mot de passe maitre sont elles concernées ?
votre avatar
Non, vu que l'étude ne les a pas regardés 😅.
Mais sinon, sur le principe, je pense que c'est pire vu que la clé d'accès est gérée uniquement par l'application sur le téléphone.

Zero Knowledge : une étude pointe les carences de Bitwarden, LastPass et Dashlane

  • La promesse du Zero Knowledge

  • Une surface d'attaque augmentée par la complexité du code

  • Les gestionnaires de mots de passe accusent réception