Évaluation de la sécurité de la génération, du stockage et du remplissage automatique des mots de passe dans les gestionnaires de mots de passe intégrés aux navigateurs

1. Introduction

L'authentification par mot de passe reste la méthode dominante pour l'authentification web, malgré ses défis de sécurité bien documentés. Les utilisateurs sont confrontés à une charge cognitive pour créer et mémoriser des mots de passe forts et uniques, ce qui conduit au réemploi de mots de passe et à la création d'identifiants faibles. Les gestionnaires de mots de passe promettent de soulager cette charge en générant, stockant et remplissant automatiquement les mots de passe. Cependant, leur sécurité a été remise en question dans des recherches antérieures. Cet article présente une évaluation de sécurité actualisée et complète de treize gestionnaires de mots de passe populaires intégrés aux navigateurs, cinq ans après la dernière publication de vulnérabilités significatives. L'étude couvre l'ensemble du cycle de vie du gestionnaire de mots de passe : génération, stockage et remplissage automatique.

2. Méthodologie et périmètre

L'évaluation a porté sur treize gestionnaires de mots de passe, incluant cinq extensions de navigateur (par exemple, LastPass, 1Password), six gestionnaires intégrés aux navigateurs (par exemple, Chrome, Firefox) et deux clients de bureau pour comparaison. La méthodologie a impliqué :

• La génération et l'analyse d'un corpus de 147 millions de mots de passe pour évaluer leur caractère aléatoire et leur robustesse.
• La réplication et l'extension d'évaluations antérieures sur la sécurité du stockage des mots de passe.
• Le test des mécanismes de remplissage automatique pour des vulnérabilités telles que le détournement de clic et le XSS.
• L'évaluation des paramètres de sécurité par défaut et des pratiques de chiffrement.

3. Analyse de la génération de mots de passe

Il s'agit de la première analyse complète des algorithmes de génération de mots de passe dans les gestionnaires de mots de passe.

4. Sécurité du stockage des mots de passe

Bien que des améliorations aient été notées par rapport aux évaluations d'il y a cinq ans, des problèmes significatifs persistent.

5. Vulnérabilités des mécanismes de remplissage automatique

La fonctionnalité de remplissage automatique, conçue pour la commodité, introduit une surface d'attaque significative.

6. Résultats et analyse comparative

Conclusion clé : Le paysage s'est amélioré depuis les études antérieures (par exemple, Li et al., 2014 ; Silver et al., 2013), mais des failles de sécurité fondamentales subsistent chez plusieurs fournisseurs. Aucun gestionnaire de mots de passe n'était irréprochable dans les trois étapes évaluées (génération, stockage, remplissage automatique). Les gestionnaires intégrés aux navigateurs et les extensions dédiées présentaient tous deux des schémas distincts de vulnérabilités.

7. Recommandations et orientations futures

L'article conclut par des recommandations actionnables :

• Pour les utilisateurs : Évitez les gestionnaires de mots de passe présentant des défauts de génération connus ou des paramètres de remplissage automatique non sécurisés par défaut. Privilégiez les gestionnaires qui permettent un contrôle granulaire du comportement de remplissage automatique.
• Pour les développeurs : Implémentez des générateurs de nombres aléatoires cryptographiquement sûrs (CSPRNG) pour la génération de mots de passe. Chiffrez toutes les métadonnées. Mettez en place des vérifications d'origine robustes et des mécanismes de consentement de l'utilisateur pour le remplissage automatique (par exemple, exiger un clic sur un élément non sujet au maquillage d'interface).
• Pour les chercheurs : Explorez l'intégration de méthodes formelles pour vérifier la logique de remplissage automatique et l'application de l'apprentissage automatique pour détecter des requêtes de remplissage automatique anormales indiquant une attaque.

8. Analyse originale et commentaires d'experts

Perspective centrale : L'étude d'Oesch et Ruoti livre une réalité qui donne à réfléchir : les outils de sécurité auxquels nous faisons confiance pour consolider nos clés numériques ont eux-mêmes été construits sur des fondations étonnamment fragiles. Cinq ans après l'exposition de failles majeures, les progrès de l'industrie sont au mieux incrémentaux, ne parvenant pas à résoudre les problèmes systémiques dans les trois piliers fondamentaux — génération, stockage et remplissage automatique. Ce n'est pas seulement un rapport de bug ; c'est une mise en accusation de la complaisance dans un secteur de sécurité critique.

Flux logique : La force de l'article réside dans son approche holistique du cycle de vie. Il identifie correctement qu'une chaîne n'est aussi forte que son maillon le plus faible. La découverte d'un manque d'aléa dans la génération ($P(car) \neq \frac{1}{N}$) sape fondamentalement toute la prémisse avant même que le stockage ou le remplissage automatique ne soient considérés. La réplication des tests antérieurs sur le stockage et le remplissage automatique montre ensuite un schéma : bien que des vulnérabilités superficielles puissent être corrigées, des défauts architecturaux (comme les métadonnées non chiffrées ou le remplissage automatique trop permissif) persistent. Cette progression logique, de la création défectueuse à la manipulation non sécurisée, puis au déploiement risqué, dresse un tableau complet et accablant.

Points forts et faiblesses : La principale force de l'étude est son approche massive et basée sur les données pour la génération de mots de passe — une première dans la littérature. Le corpus de 147 millions de mots de passe fournit une preuve statistique irréfutable de faiblesse algorithmique, dépassant les préoccupations théoriques. Cependant, l'analyse présente un angle mort : elle traite largement les gestionnaires de mots de passe comme des clients isolés. La réalité moderne est la synchronisation cloud et les applications mobiles. Comme noté dans les actes du IEEE Symposium on Security and Privacy sur les modèles de sécurité cloud, la surface de menace s'étend aux protocoles de synchronisation, aux API côté serveur et à l'intégration avec le système d'exploitation mobile, que cette étude n'évalue pas. De plus, bien qu'elle mentionne des "paramètres par défaut non sécurisés", elle ne quantifie pas le taux d'adoption par les utilisateurs des paramètres sécurisés — un facteur critique dans le risque réel, comme le montrent régulièrement les études d'utilisabilité de la conférence USENIX SOUPS selon lesquelles la plupart des utilisateurs ne changent jamais les paramètres par défaut.

Perspectives actionnables : Pour les équipes de sécurité d'entreprise, cette recherche impose un changement : il ne s'agit plus de recommander globalement "d'utiliser un gestionnaire de mots de passe", mais de fournir des conseils spécifiques aux fournisseurs et à la configuration. Les gestionnaires avec des générateurs faibles doivent être mis sur liste noire. Les listes de contrôle des achats doivent désormais inclure la vérification de l'utilisation de CSPRNG et du chiffrement des métadonnées. Pour les développeurs, la voie à suivre est claire : adopter un principe de "confiance zéro" pour le remplissage automatique, exigeant un consentement utilisateur explicite et contextuel pour chaque action de remplissage, similaire aux modèles d'autorisation préconisés par le World Wide Web Consortium (W3C) pour les API web puissantes. L'avenir ne réside pas dans la tentative de sécuriser parfaitement un remplissage automatique trop permissif, mais dans la conception d'un mécanisme minimalement permissif et contrôlé par l'utilisateur. L'incapacité de l'industrie à s'autocorriger en cinq ans suggère qu'une intervention réglementaire ou d'organismes de normalisation (par exemple, par le NIST ou la FIDO Alliance) pourrait être nécessaire pour imposer des exigences de sécurité de base à ces gardiens de notre identité numérique.

9. Détails techniques et résultats expérimentaux

Analyse de la génération de mots de passe : L'entropie $H$ d'un mot de passe généré de longueur $L$ à partir d'un jeu de caractères $C$ est idéalement $H = L \cdot \log_2(|C|)$ bits. L'étude a trouvé des cas où l'entropie effective était plus faible en raison d'une sélection biaisée des caractères. Par exemple, si un générateur est censé utiliser un jeu de 94 caractères mais que certains caractères apparaissent avec une probabilité $p \ll \frac{1}{94}$, l'entropie réelle est réduite : $H_{réelle} = -\sum_{i=1}^{94} p_i \log_2(p_i)$ par caractère, où $\sum p_i = 1$.

Description du graphique expérimental : Un graphique clé de l'étude tracerait la fraction cumulée des mots de passe craqués en fonction du nombre de tentatives de devinette (échelle logarithmique) pour des mots de passe générés de différentes longueurs (par exemple, 8, 12, 16 caractères). La courbe pour les mots de passe de moins de 10 caractères montrerait une augmentation abrupte, indiquant une compromission rapide dans des simulations d'attaque en ligne (par exemple, 1000 tentatives). La courbe pour les mots de passe de moins de 18 caractères montrerait une fraction significative craquée après $10^{10}$ à $10^{12}$ tentatives hors ligne, les plaçant à la portée d'attaquants déterminés avec du matériel moderne, comme le démontrent des outils comme Hashcat et les tables arc-en-ciel.

10. Cadre d'analyse et étude de cas

Cadre pour l'évaluation de la sécurité des gestionnaires de mots de passe :

1. Intégrité de la génération : Tester statistiquement la sortie pour le caractère aléatoire (par exemple, tests NIST STS, Dieharder) et calculer l'entropie effective. Vérifier que les longueurs minimales par défaut sont conformes aux directives NIST actuelles (>= 12 caractères).
2. Sécurité du stockage : Inspecter le stockage local (par exemple, IndexedDB du navigateur, fichiers SQLite) et le trafic réseau pour distinguer les données chiffrées du texte clair. Auditer la bibliothèque de chiffrement et la fonction de dérivation de clé (par exemple, utilise-t-elle PBKDF2 avec un nombre d'itérations suffisant, ou Argon2 ?).
3. Posture de sécurité du remplissage automatique : Cartographier le mécanisme de déclenchement du remplissage automatique. Tester le maquillage d'interface en créant des iframes superposées. Tester la logique de correspondance d'origine en déployant des sites avec des noms de domaine similaires (par exemple, `example.com` vs `example.com.evil.net`). Vérifier si le remplissage automatique nécessite un geste de l'utilisateur sur un élément de page non prévisible.

Étude de cas - Vulnérabilité de détournement de clic : Prenons le Gestionnaire X, qui affiche un bouton de remplissage automatique au-dessus d'un formulaire de connexion. Un attaquant crée une page malveillante avec un iframe invisible chargeant `bank.com`. L'iframe est positionnée de sorte que le bouton de remplissage automatique du Gestionnaire X apparaisse au-dessus d'un bouton caché "soumettre-à-l'attaquant" sur la page malveillante. L'utilisateur clique pour remplir automatiquement, mais clique à la place sur le bouton de l'attaquant, envoyant les identifiants de `bank.com` au serveur de l'attaquant. Cela démontre un échec dans la liaison des événements de clic et la validation de l'origine du gestionnaire.

11. Applications futures et perspectives de recherche

Les résultats ouvrent plusieurs pistes pour des travaux futurs :

• Génération et stockage assistés par matériel : Intégration avec des modules de plateforme sécurisée (TPM) ou des enclaves sécurisées (par exemple, le Secure Element d'Apple) pour générer des graines aléatoires et stocker des clés de chiffrement, déplaçant ainsi les secrets hors des domaines purement logiciels.
• Remplissage automatique contextuel et basé sur le risque : Exploiter l'apprentissage automatique pour analyser le contexte de la page (structure DOM, détails du certificat, réputation du site) afin d'évaluer le risque de remplissage automatique. Un contexte à haut risque pourrait nécessiter une authentification supplémentaire (biométrique) ou bloquer complètement le remplissage automatique.
• API de sécurité standardisées : Développement d'une API normalisée et soumise à autorisation pour les gestionnaires de mots de passe (par exemple, un successeur de l'API `chrome.loginState`) qui fournit un accès sécurisé et isolé aux identifiants avec des invites de consentement utilisateur claires, réduisant ainsi la surface d'attaque provenant d'injections DOM arbitraires.
• Préparation à la cryptographie post-quantique : Recherche sur la migration du chiffrement des gestionnaires de mots de passe vers des algorithmes résistants aux attaques des ordinateurs quantiques, car le coffre-fort chiffré est un actif à longue durée de vie très attractif pour les adversaires de type "récolter maintenant, déchiffrer plus tard".
• Modèles décentralisés et d'auto-gestion : Exploration de l'utilisation de protocoles d'identité décentralisés (par exemple, basés sur les W3C Verifiable Credentials) pour réduire la dépendance à un coffre-fort central, distribuer le risque et donner aux utilisateurs un plus grand contrôle.

12. Références

1. Oesch, S., & Ruoti, S. (2020). That Was Then, This Is Now: A Security Evaluation of Password Generation, Storage, and Autofill in Browser-Based Password Managers. USENIX Security Symposium.
2. Li, Z., He, W., Akhawe, D., & Song, D. (2014). The Emperor's New Password Manager: Security Analysis of Web-based Password Managers. IEEE Symposium on Security and Privacy (SP).
3. Silver, D., Jana, S., Boneh, D., Chen, E., & Jackson, C. (2013). Password Managers: Attacks and Defenses. USENIX Security Symposium.
4. National Institute of Standards and Technology (NIST). (2017). Digital Identity Guidelines (SP 800-63B).
5. Stock, B., & Johns, M. (2013). Protecting the Intranet Against "JavaScript Malware" and Related Attacks. International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA).
6. Herley, C. (2009). So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users. Proceedings of the New Security Paradigms Workshop (NSPW).
7. World Wide Web Consortium (W3C). (2021). Permissions Policy. https://www.w3.org/TR/permissions-policy-1/
8. FIDO Alliance. (2022). FIDO2: WebAuthn & CTAP. https://fidoalliance.org/fido2/