Ce que le serveur peut lire, et ce qu’il ne peut pas
Votre coffre-fort est chiffré sur votre appareil avec une clé que le serveur ne reçoit jamais. Cette phrase figure sur le site de tous les gestionnaires de mots de passe ; cette page fait donc la partie qui manque d’habitude : elle dit exactement quelles valeurs sont dérivées où, laquelle est envoyée, ce que le serveur voit malgré tout, et où le modèle est plus faible que le slogan.
Tout ce qui suit est vérifiable. Quand une affirmation repose sur un mécanisme plutôt que sur une promesse, le mécanisme est nommé.
Les affirmations de cette page ont été relues dans le code source le
D’où vient chaque clé
Votre mot de passe maître n’est jamais transmis, et la clé qui déchiffre votre coffre-fort ne l’est pas davantage. Les deux sont produites sur votre appareil, à partir du mot de passe et de votre adresse e-mail, à chaque connexion.
Une valeur dérivée part bien vers le serveur : c’est la troisième étape ci-dessous. C’est une fonction à sens unique d’une fonction à sens unique de votre mot de passe — suffisante pour prouver que vous le connaissez, inutile pour déchiffrer quoi que ce soit.
Mot de passe maître + votre adresse e-mail comme selArgon2idClé maîtresse, 32 octets
Gourmande en mémoire à dessein : les paramètres de coût sont choisis pour rendre une attaque à grande échelle coûteuse, même avec l’empreinte en main. Le calcul a lieu dans votre navigateur, dans l’extension, ou nativement sur votre téléphone.
Clé maîtresseHKDF-SHA256, info « stretch »Clé étendue
Une seule dérivation se sépare ensuite en deux valeurs indépendantes, si bien qu’aucune ne permet de calculer l’autre.
Clé étendueSHA-256Empreinte du mot de passe maître
C’est la seule valeur dérivée qui soit envoyée. Le serveur la hache à nouveau avec bcrypt avant de la stocker : ce qui se trouve en base est donc un bcrypt d’un SHA-256 d’un HKDF d’un Argon2id. Elle vérifie une connexion et ne déchiffre rien.
Clé étendueHKDF-SHA256, info « vault »Clé du coffre-fort
Jamais envoyée, jamais journalisée, jamais mise sous séquestre. Elle n’existe que pour déballer la clé suivante.
Clé du coffre-fortAES-256-GCMVotre clé privée X25519
Chaque compte possède une paire de clés X25519. La moitié publique est stockée en clair ; la moitié privée n’est stockée que sous forme de chiffré que le serveur ne peut pas ouvrir. C’est cette indirection qui fait qu’un changement de mot de passe maître n’oblige pas à rechiffrer le coffre-fort.
Votre clé privée X25519clé de groupe, puis clé de dossierLes éléments eux-mêmes
Votre clé privée déballe la clé de chaque groupe dont vous faites partie ; une clé de groupe déballe la clé de chaque dossier que ce groupe peut lire ; une clé de dossier déchiffre les éléments qu’il contient.
- Argon2id · 64 Mio de mémoire · 3 passes · 4 voies · sortie de 32 octets
- AES-256-GCM · un nonce aléatoire de 96 bits, neuf à chaque chiffrement
- Vérification de fuite · 5 caractères d’une empreinte SHA-1 quittent l’appareil, et rien d’autre
Les paramètres de coût sont récupérés auprès du serveur à la connexion parce qu’ils doivent correspondre à ceux utilisés à la création du compte. En envoyer de plus faibles ne vous affaiblirait pas en silence : cela produirait une empreinte différente, et la connexion échouerait tout simplement.
Un élément est scellé avec la clé du dossier où il se trouve
Chaque élément est chiffré en AES-256-GCM avec la clé de son dossier, et un nonce aléatoire neuf à chaque chiffrement — un nouveau à chaque enregistrement, jamais réutilisé. Ce qui parvient au serveur, c’est le chiffré, le nonce, et les champs de structure nécessaires pour stocker la ligne.
L’historique des versions est le même chiffré, conservé par révision : retrouver la valeur de la semaine dernière est donc un déchiffrement côté client d’un ancien bloc, et non un service que le serveur vous rend. Les noms de dossiers sont chiffrés eux aussi : le serveur détient l’arborescence, pas les étiquettes posées dessus.
L’accès à un dossier est cryptographique, pas un simple drapeau
C’est la partie la plus utile à vérifier, parce que c’est là que beaucoup de produits se contentent d’un booléen. Donner à un groupe l’accès à un dossier écrit à ce groupe sa propre copie de la clé du dossier, chiffrée pour que seuls ses membres puissent l’ouvrir. L’autorisation et la clé sont la même ligne.
Révoquer un groupe supprime donc sa copie de la clé. Il ne reste pas un drapeau à « faux » avec une clé lisible derrière, et aucun chemin de code ne laisse le serveur décider de livrer du clair — il n’a pas de clair à livrer. C’est la même construction qui rend le plan gratuit mono-utilisateur : sans groupe, il n’y a personne pour qui envelopper une clé de dossier.
La révocation ne vaut que pour l’avenir, comme dans tout système de cette forme. Supprimer une copie de clé empêche les lectures futures ; cela ne peut pas effacer ce que quelqu’un a déjà déchiffré. Quand une personne part, changez les identifiants eux-mêmes, pas seulement ses accès.
Vos secrets à deux facteurs n’y sont pas, volontairement
Le coffre-fort n’a aucun champ pour un secret TOTP et n’en aura pas. C’est une position de conception, pas un manque sur la feuille de route, et cela mérite d’être dit clairement parce que les stocker ensemble est courant.
Un mot de passe et son second facteur dans le même magasin ne font pas deux facteurs. Ce qui atteint ce magasin atteint les deux d’un coup, et le second facteur a cessé d’être un second quoi que ce soit — ce qui est précisément la raison d’en avoir un. Les garder séparés est la fonctionnalité.
L’outil d’import tient la ligne là où il serait le plus facile de la franchir : si un fichier importé contient des graines d’authentification, elles sont extraites avant tout chiffrement, jamais envoyées, et vous sont rendues à la fin sous forme de QR codes otpauth:// à scanner dans une application d’authentification. Un produit distinct est la réponse honnête ici, et nous en publions un.
Une surveillance des fuites qui n’envoie jamais un mot de passe
Les mots de passe enregistrés sont comparés à des corpus de fuites connus sans que le mot de passe, ni son empreinte complète, ne quitte votre appareil. Le client calcule localement une empreinte SHA-1, envoie les cinq premiers caractères hexadécimaux, et compare le reste à la réponse en mémoire.
Cinq caractères représentent environ un millionième de l’espace des empreintes, partagé avec des centaines de milliers de mots de passe sans rapport. Le serveur apprend un préfixe, jamais quelle entrée a correspondu, ni même si quelque chose a correspondu. La requête passe par notre backend au lieu de partir de votre navigateur, ce qui garde aussi votre adresse IP hors de portée du tiers.
Le rapport de ce qui a été trouvé est lui-même chiffré avant d’être stocké, et lié à votre compte : un bloc prélevé sur un compte échoue au déchiffrement pour un autre au lieu de s’ouvrir dans le mauvais tableau de bord.
Perdre son mot de passe, et la seule voie de retour
Vous pouvez générer une clé de récupération. Elle a une forte entropie, elle est affichée une seule fois, et le serveur ne la voit jamais : ce que le serveur stocke, c’est une seconde copie de votre clé privée X25519, enveloppée sous une clé dérivée de la clé de récupération. Présenter la clé de récupération déballe cette copie et rétablit l’accès.
Si vous n’en avez pas créé et que vous oubliez votre mot de passe maître, vos données sont perdues et nous ne pouvons rien faire — « ne pouvons pas », et non « ne voulons pas ». C’est le prix du reste de cette page, et c’est le bon sens de la contrainte : un fournisseur capable de récupérer votre coffre-fort est un fournisseur capable de le lire.
Une séparation non cryptographique, mais structurelle
Chaque ligne de la base porte un identifiant d’espace de travail, et la sécurité au niveau des lignes de PostgreSQL rejette toute requête qui n’en précise pas un — un accès entre espaces est donc un refus de la base de données, et non un filtre qu’un gestionnaire doit penser à ajouter.
Les sessions reposent sur des jetons d’accès de courte durée et des jetons de renouvellement rotatifs dans des cookies HTTP-only. Les clés d’API ont une portée limitée et sont stockées sous forme d’empreintes SHA-256 : la clé que nous détenons ne permet pas d’émettre une requête. Rien de cela ne protège votre clair — c’est le chiffrement qui s’en charge — mais c’est ce qui sépare deux clients, et une clé volée de votre espace.
Ce que nous voyons
Une page « zéro connaissance » qui n’énumère que ce qui est caché n’est pas crédible ; voici donc l’autre colonne. Le serveur sait nécessairement beaucoup de choses sur la forme de votre coffre-fort, puisqu’il doit le stocker, l’indexer et le facturer.
Cette liste a été établie à partir du schéma de la base de données, et non écrite d’après nos intentions. Si vous trouvez quelque chose que nous détenons et qui n’y figure pas, c’est une erreur de cette page et nous voulons le savoir.
Chiffré uniquement — illisible pour nous
- Le contenu de chaque élément : noms, identifiants, mots de passe, notes, numéros de carte, clés, tous les champs
- Les noms de dossiers
- Toutes les versions antérieures de chaque élément
- Le contenu derrière un lien de partage public — sa clé voyage dans le lien, pas dans notre base
- Votre clé privée X25519, stockée enveloppée sous la clé de votre coffre-fort
- Votre mot de passe maître et la clé de votre coffre-fort, qui ne sont jamais envoyés
- Vos secrets à deux facteurs, qui ne sont stockés ici sous aucune forme
En clair — tout cela nous est visible
- Combien d’éléments vous avez, et de quel TYPE est chacun : identifiant, note sécurisée, carte, document, Wi-Fi, clé d’API, clé SSH, base de données, serveur
- Quand chaque élément a été créé et modifié pour la dernière fois, combien de révisions il compte, et quand il doit expirer
- Dans quel dossier se trouve chaque élément, la forme de votre arborescence, et combien de dossiers elle contient
- Quel membre a créé chaque élément
- L’adresse e-mail et le nom complet de chaque membre, sa date de naissance s’il l’a renseignée, et sa photo de profil
- Les noms de vos groupes, en clair, et qui appartient à chaque groupe
- Le nom de votre espace de travail, son plan, son état de facturation, les dates d’essai, et votre identifiant client chez le prestataire de paiement
- Le journal d’audit : chaque action, le type de ressource touchée, l’heure exacte, et l’adresse IP d’où elle provenait
- Pour chaque lien de partage : son existence, sa durée de vie, s’il a une phrase secrète, s’il s’autodétruit à la première lecture, combien de fois il a été ouvert et quand
- L’empreinte de votre mot de passe maître — de quoi vérifier une connexion, pas de quoi déchiffrer quoi que ce soit
- Les préfixes d’empreinte de cinq caractères qu’envoie une vérification de fuite, et les adresses d’où viennent vos sessions
Rien de tout cela n’est vos mots de passe. Tout cela est de l’information sur vous, et des métadonnées ne sont pas rien.
Dit aussi crûment que cela le mérite : une personne ayant accès à notre base pourrait constater que vous conservez quatre cartes de paiement, qu’un dossier dont elle ne peut pas lire le nom a gagné un élément à 2 h 14 un dimanche, et depuis quelle adresse. Elle ne pourrait pas vous dire ce que tout cela contient.
Là où c’est plus faible que le slogan
Quatre endroits. Aucun n’est un défaut que nous allons corriger, et c’est pourquoi ils sont écrits ici plutôt que laissés à découvrir.
Sur un téléphone, la clé est conservée au repos
« Ne quitte jamais l’appareil » parle du réseau, pas de la mémoire. Sur le web et dans l’extension, la clé du coffre-fort n’existe qu’en mémoire vive, le temps de la session. Sur iOS et Android, elle est conservée dans le porte-clés du système d’exploitation, protégée par la plateforme et libérée seulement après une vérification biométrique ou le code de l’appareil.
C’est cela que relit le déverrouillage biométrique, et ce n’est volontairement pas effacé au verrouillage de l’application — l’effacer rendrait le déverrouillage biométrique impossible, puisque rien sur ce chemin ne peut redériver la clé depuis un mot de passe maître qui n’est conservé nulle part. La déconnexion, elle, la supprime.
La conséquence, dite simplement : sur un téléphone, le plancher de sécurité est l’authentification de l’appareil, pas votre mot de passe maître. Qui sait déverrouiller votre téléphone peut ouvrir votre coffre-fort. C’est un compromis assumé, figé par un test pour que le modifier soit une décision et non un nettoyage.
Sur le web, c’est nous qui servons le code qui chiffre
Une application web est téléchargée à neuf à chaque visite : son intégrité dépend donc de nous, qui devons livrer du code honnête, et de cette livraison, qui ne doit pas être altérée. Aucune cryptographie côté client n’échappe à cela : le client est le nôtre.
Les clients empaquetés sont en meilleure position sur ce risque précis. L’extension est un paquet versionné et signé, distribué par le Chrome Web Store, et les applications mobiles sont des builds signés des magasins — chacun est un artefact figé, inspectable, plutôt qu’un téléchargement à refaire confiance à chaque fois. Si c’est votre modèle de menace, préférez-les.
Il n’existe aucun audit externe publié
La construction employée ici est standard — Argon2id, HKDF, AES-256-GCM, X25519, utilisés de façon ordinaire et avec des implémentations bien relues — mais personne d’extérieur à l’équipe n’a publié de revue de cette implémentation-ci, et nous n’allons pas laisser croire le contraire en contournant le sujet.
Ce que nous offrons à la place, c’est la précision : cette page nomme le mécanisme derrière chaque affirmation, pour que vous puissiez vérifier le comportement vous-même au lieu de vous fier à un certificat. Un certificat serait mieux. Il n’existe pas encore.
Le partage est plus étroit que vous ne l’imaginez peut-être
Il n’y a pas de partage de personne à personne, ni de coffre-fort partagé à l’échelle de l’organisation. Les deux mécanismes existants sont l’accès d’un groupe à un dossier, au sein d’un espace de travail, et un lien public temporaire vers un seul élément.
Un lien public reste « zéro connaissance » — sa clé est dans le lien, nous ne pouvons donc pas lire ce qui a été partagé — mais c’est un lien, et quiconque l’a peut l’ouvrir jusqu’à son expiration, son autodestruction ou sa révocation. Voyez-le comme un moyen de transmettre quelque chose une fois, pas de donner un accès durable à un collègue.
Quel plan donne quoi, là-dedans
La cryptographie n’en fait pas partie. La dérivation des clés, le chiffrement des éléments et le modèle « zéro connaissance » sont identiques sur tous les plans, gratuit compris — il n’existe aucune version de ce produit où payer davantage signifierait un meilleur chiffrement.
- Chiffrement côté client, clés par dossier, historique des versions, connexion multifacteur et confiance d’appareil : tous les plans, gratuit compris
- Surveillance des fuites sur les mots de passe enregistrés : plans payants
- Délais de verrouillage automatique, réglables par surface pour le web, l’extension et le mobile : tous les plans. Le PLAFOND à l’échelle de l’espace qu’un administrateur peut imposer aux trois : plans payants
- Authentification unique OIDC ou SAML, sur un domaine vérifié par DNS, avec provisionnement à la volée, application facultative et une voie de secours pour le propriétaire : Premium
- Journal d’audit : la fenêtre correspond à la fois à la profondeur de consultation et à la durée de conservation, et elle s’allonge avec le plan
- Accès API avec des clés à portée limitée, stockées sous forme d’empreintes : Premium
- Isolation des espaces de travail au niveau des lignes en base : ce n’est pas une option de plan, c’est la construction de la base
Comment le vérifier vous-même
Quatre choses vérifiables sans notre aide. Si l’une d’elles ne se comporte pas comme décrit, cette page est fausse et nous aimerions le savoir.
- Ouvrez l’inspecteur réseau de votre navigateur et enregistrez un élément. Le corps de la requête contient un bloc chiffré et un nonce. Aucun champ ne contient ce que vous avez saisi.
- Changez votre mot de passe maître et regardez ce qui est envoyé : votre clé privée réenveloppée, et non vos éléments. Ce n’est possible que parce que les éléments n’ont jamais été chiffrés avec le mot de passe.
- Décompressez l’extension de navigateur depuis le Chrome Web Store et lisez le code qui dérive la clé et chiffre l’élément. C’est un artefact publié et versionné, pas quelque chose que nous vous livrons différemment chaque fois.
- Demandez-nous tout ce que nous détenons sur vous. Ce que nous pouvons produire, c’est le chiffré et les métadonnées listées plus haut — c’est vraiment tout.
Questions fréquentes sur le modèle
- U2 Secured peut-il lire mes mots de passe ?
- Non. Les éléments sont chiffrés sur votre appareil en AES-256-GCM avec une clé dérivée de votre mot de passe maître par Argon2id puis HKDF, et cette clé n’est jamais transmise. Le serveur stocke un chiffré et un nonce. La seule valeur dérivée qu’il reçoive est une empreinte servant à vérifier votre connexion, qu’il hache à nouveau avec bcrypt avant de la stocker.
- Que voyez-vous, si ce ne sont pas les mots de passe ?
- La structure et les horodatages. Combien d’éléments vous avez et de quel type, la forme de votre arborescence de dossiers, qui a créé quoi et quand, les noms de vos groupes, les noms et adresses e-mail de vos membres, le journal d’audit avec les adresses IP d’origine, et vos données de facturation. Les noms de dossiers, le contenu des éléments et l’historique des versions sont chiffrés. La liste complète est sur cette page.
- Que se passe-t-il si vos serveurs sont compromis ?
- Qui emporterait les données détiendrait un chiffré dont il n’a aucune clé, les métadonnées listées plus haut, et des empreintes bcrypt de valeurs déjà dérivées. Il verrait la forme de votre coffre-fort. Il ne pourrait pas le lire, et aucune clé de notre côté n’y changerait quoi que ce soit — les clés sont sur vos appareils.
- Pourquoi mes codes à deux facteurs ne sont-ils pas dans le coffre-fort ?
- Parce qu’un mot de passe et son second facteur dans un même magasin ne font pas deux facteurs : ce qui ouvre ce magasin ouvre les deux. Le coffre-fort n’a aucun champ pour un secret TOTP, et l’outil d’import extrait volontairement ceux qu’il trouve pour vous les rendre sous forme de QR codes otpauth:// au lieu de les envoyer. L’Authenticator est un produit distinct pour la même raison.
- L’application mobile est-elle aussi sûre que le site web ?
- Elle est différente, plutôt que simplement meilleure ou moins bonne. Le téléphone conserve la clé de votre coffre-fort au repos dans le porte-clés du système, libérée après une biométrie ou le code de l’appareil : le plancher y est donc l’authentification de l’appareil et non votre mot de passe maître. En échange, un build de magasin est un artefact signé et figé, et non du code relivré à chaque visite. Les deux faits sont détaillés sur cette page.
- Si j’oublie mon mot de passe maître, pouvez-vous le réinitialiser ?
- Seulement si vous avez créé une clé de récupération au préalable, que nous ne voyons jamais — elle déballe une seconde copie stockée de votre clé privée. Sans elle, nous ne pouvons pas récupérer votre coffre-fort. Un fournisseur qui en serait capable serait un fournisseur capable de le lire.
- Le chiffrement est-il plus faible sur le plan gratuit ?
- Non. La dérivation des clés, le chiffrement des éléments et le modèle « zéro connaissance » sont identiques sur tous les plans. Ce que les plans payants ajoutent est d’ordre organisationnel : plus de capacité, la surveillance des fuites, un journal d’audit plus long, l’authentification unique et l’accès API.
Lisez, puis essayez
Un espace gratuit ne demande aucune carte et utilise exactement l’architecture décrite ci-dessus. Si quelque chose sur cette page ne correspond pas à ce que vous observez, dites-le nous — c’est un défaut de la page ou du produit, et les deux comptent.