Ce que « gestionnaire de mots de passe open source » devrait vouloir dire
Tous les gestionnaires de mots de passe affirment que vos données sont en sécurité. Cette affirmation est invérifiable tant que vous ne pouvez pas lire le code qui les chiffre. C'est pour cette raison qu'« open source » compte ici comme nulle part ailleurs, et que le label mérite d'être interrogé plutôt que cru sur parole.
La partie qui doit être ouverte, c'est le client
Dans une architecture zero-knowledge, le chiffrement a lieu sur votre appareil avant toute transmission. Le serveur ne reçoit que du texte chiffré. La promesse de sécurité repose donc entièrement sur le client : l'extension navigateur, l'application mobile, l'application de bureau.
Un éditeur qui publie son serveur mais pas son client a publié la partie qui ne peut pas vous trahir, et gardé celle qui le peut. C'est la mauvaise moitié. Si vous ne pouvez auditer qu'un seul composant, c'est le client qui compte.
Votre extension est déjà lisible, la question est celle de l'honnêteté
Ce que peu de gens réalisent : une extension navigateur n'est pas compilée en code machine. Un fichier .crx ou .xpi est une archive zip de JavaScript. N'importe qui peut la télécharger et la lire aujourd'hui, minifiée mais parfaitement analysable.
Publier le code d'une extension ne révèle donc rien qu'un attaquant ne puisse déjà obtenir. Ce que cela change, c'est l'honnêteté : du code lisible, de vrais noms de variables, des commentaires qui expliquent le raisonnement, et un historique montrant ce qui a changé et quand.
Quatre questions à poser à n'importe quel éditeur
- Le client est-il publié, ou seulement le serveur ? C'est dans le client que vos secrets sont manipulés.
- La cryptographie est-elle dans le dépôt publié ? Un dépôt qui contient l'interface mais importe le chiffrement depuis un paquet fermé relève de la mise en scène.
- Chaque version est-elle taguée ? Sans tag correspondant à ce qui est sur le store, impossible de vérifier que le code publié est celui que vous avez installé.
- Existe-t-il une politique de sécurité ? Un projet qui souhaite être scruté publie comment signaler une faille, et ce qu'il s'engage à faire en retour.
Ce que SandPass publie
L'extension SandPass et l'intégralité de sa cryptographie sont publiques sous licence GPL-3.0 sur github.com/sandprivacy/sandpass-extension. Cela comprend :
- L'extension complète : popup, panneau latéral, service worker et remplissage automatique.
@sandpass/crypto: dérivation de clés, chiffrement AES-256-GCM, client OPAQUE, TOTP et génération de mots de passe.@sandpass/core: le client API et le service de coffre.
Chaque version est taguée, et le tag correspond exactement à l'arbre source qui a produit le build. Si vous constatez une divergence entre un tag et l'extension installée depuis le store, c'est un problème de sécurité et nous voulons le savoir.
Ce que SandPass ne publie pas, et pourquoi nous le disons
Le backend n'est pas public. Nous préférons l'énoncer clairement plutôt que de laisser le terme « open source » suggérer davantage qu'il ne recouvre.
Le raisonnement : en modèle zero-knowledge, le serveur ne reçoit que des données déjà chiffrées, et le client publié suffit à le constater. Publier le code serveur ne prouverait d'ailleurs rien sur le code réellement exécuté en production, puisque vous devriez toujours nous croire sur parole. L'audit qui compte est celui que vous pouvez mener vous-même, et il porte sur le client.
Nous publions aussi ce que nous acceptons
Notre politique de sécurité énumère les limitations que nous connaissons et avons délibérément acceptées, dont des contraintes imposées par Manifest V3 que partage tout gestionnaire de mots de passe en extension, comme le passage de matériel de clé par chrome.storage.session.
Nous préférons les énoncer nous-mêmes plutôt que quelqu'un les découvre et se demande ce qui d'autre est passé sous silence. Un éditeur qui n'a rien à divulguer est généralement un éditeur qui n'a pas cherché.
Lisez avant d'accorder votre confiance
Nul besoin d'être cryptographe. Ouvrez le dépôt, regardez si les commentaires expliquent un raisonnement ou paraphrasent le code, vérifiez si les versions sont taguées, lisez la politique de sécurité. Ces signaux en disent long sur le sérieux d'une équipe vis-à-vis de ce qu'elle vous demande de lui confier.