Sécurité et confiance

• Votre navigateur chiffre localement.
• Notre serveur ne stocke votre secret que sous forme chiffrée.
• La clé privée reste dans votre lien.
• Après la première lecture réussie, l'enregistrement est supprimé.
• Le code est vérifiable publiquement.
• Nous documentons ouvertement nos limites.

• AES-GCM-256 via l'API WebCrypto native du navigateur ; aucune bibliothèque cryptographique tierce sur le réseau. secrets.js:211-217
• Accord de clés X25519 combiné à une dérivation HKDF-SHA256, le tout réalisé dans le navigateur avec WebCrypto. secrets.js:256-269, secrets.js:425-453
• Nonce aléatoire de 12 octets par texte chiffré (IV GCM de 96 bits), jetons aléatoires de 22 caractères compatibles URL (128 bits d'entropie). SecretService.php:24, SecretService.php:36-38
• Protection facultative par mot de passe : PBKDF2-SHA256 avec 1 200 000 itérations conformément aux recommandations OWASP 2024 ; le sel et le nombre d'itérations voyagent dans le fragment de l'URL, de sorte que les anciens liens continuent de fonctionner. SecretService.php:52, secrets.js:271-293

• Suppression définitive dès la première lecture réussie, via un DELETE...RETURNING atomique. Aucune table de suppression logique, aucune sauvegarde applicative des enregistrements chiffrés. Les journaux de transactions de la base (WAL) sont écrasés en continu et ne sont pas archivés ; les sauvegardes quotidiennes des serveurs sont écrasées au bout de 7 jours, et le texte chiffré qu'elles contiennent reste illisible. SecretService.php:55-79
• Limite par IP de 10 créations et 20 récupérations par minute, plus un plafond global de 200 écritures et 500 lectures par minute afin de protéger la disponibilité. Create.php:82 , Retrieve.php:42
• La durée de vie est imposée côté serveur, entre 1 minute et 7 jours, et jusqu'à 30 jours dans les formules Pro et Business. L'interface web propose des préréglages de 1 heure, 24 heures et 7 jours ; les clients de l'API peuvent choisir n'importe quelle valeur dans la plage de leur formule. SecretsValidators.php:43-52
• Charge utile chiffrée limitée à 1 Mo, imposée dans le validateur et dans la couche de service. SecretService.php:28, SecretService.php:300-306

• La page d'état en temps réel expose le SHA du commit déployé et l'environnement, afin que vous puissiez figer le build en cours d'exécution. /status
• Un fichier security.txt conforme à la RFC 9116, avec contact, clé PGP, politique et remerciements. /.well-known/security.txt
• Le service backend et la cryptographie du navigateur sont publiés sous licence AGPL-3.0 sur un miroir public. LICENSE

• Comme pour tout outil cryptographique sur le web, la protection ne tient que tant que le JavaScript que nous livrons est bien celui que nous entendons livrer. Une compromission du serveur (ou une attaque de l'intercepteur TLS réussie avec un certificat de confiance) pourrait substituer un bundle malveillant qui exfiltrerait le texte en clair avant chiffrement. Le bundle principal est désormais livré avec une empreinte Subresource Integrity appliquée par le navigateur ; elle bloque un fichier substitué, mais pas un serveur qui publie l'empreinte correspondante avec un bundle altéré. Les scripts des composants web, les bibliothèques tierces et les feuilles de style ne portent aucune empreinte.
• Aucun audit cryptographique par un tiers n'a encore été publié. Tant qu'il n'existe pas, la « confiance » repose sur le miroir open source et sur votre propre relecture.

Le texte en clair reste dans votre navigateur, mais le serveur observe malgré tout certaines choses du simple fait qu'il fait tourner le service.

• Les libellés facultatifs voyagent encodés en base64 dans le fragment de l'URL afin que l'expéditeur puisse les prévisualiser. Considérez-les comme des métadonnées d'URL, non comme du contenu chiffré ; ne mettez aucune information secrète dans le champ libellé.
• Les notes du tableau de bord sont stockées en clair à côté de l'enregistrement de propriété et sont lisibles par nous et par tous les membres de votre organisation. Indiquez-y à quoi servait un secret, jamais une information secrète elle-même.
• La longueur du texte chiffré est stockée telle quelle : la taille en octets d'un secret est donc observable par quiconque a accès à la base de données.
• Les journaux applicatifs enregistrent des empreintes de requêtes par IP (SHA-256 tronqué, jamais l'IP brute) et des motifs de routes. Les segments de jeton sont expurgés avant journalisation par le filtre de rédaction SecretLogger.
• Un observateur du réseau, entre vous et notre serveur, peut voir la taille des requêtes et leurs motifs temporels. Le remplissage du texte chiffré à une longueur fixe est prévu dans la feuille de route ; aujourd'hui, la taille correspond à ce que vous avez saisi, plus une balise GCM de 16 octets.

• Choisissez la durée de vie la plus courte possible. Prenez une heure par défaut pour les secrets ponctuels et n'allez jusqu'à sept jours que si le destinataire est hors ligne.
• Ajoutez un mot de passe au secret. Le destinataire aura besoin du lien et du mot de passe : un lien qui fuite ne sert alors à rien. Le mot de passe dérive une clé supplémentaire via PBKDF2-SHA256 avec 1,2 million d'itérations.
• Laissez le libellé vide si le contexte du secret est lui-même sensible. Les libellés voyagent dans le fragment de l'URL pour la prévisualisation de l'expéditeur, mais ils ne sont pas du contenu chiffré.
• Envoyez le lien par un canal et le mot de passe par un autre. La compromission d'un seul canal ne divulgue alors ni l'un ni l'autre.
• Avant de coller un secret, vérifiez que la barre d'adresse indique exactement vault.erseni.com ou votre domaine auto-hébergé. Un domaine sosie hébergeant un bundle malveillant est l'attaque la plus concrète contre cette architecture.

Si vous êtes journaliste, militant, ou si vous vous attendez à un adversaire disposant de moyens importants, la cryptographie livrée par le navigateur n'est pas l'outil le plus robuste à votre disposition. Considérez Vault comme une couche de confort au modèle de menace documenté, et non comme un substitut aux pratiques ci-dessous.

• Faites tourner votre propre instance sur votre propre domaine. Vous faites alors confiance à votre build JavaScript plutôt qu'au nôtre.
• Pour les secrets de longue durée, préférez un outil hors ligne : age, GPG, ou un flux adossé à un jeton matériel. Ils sont auditables sans serveur en fonctionnement.
• Lisez la source de secrets.js avant de vous fier à un déploiement vault.erseni.com. Le bundle est assez court pour être relu sur un seul écran.
• Pour les phrases de récupération, le matériel cryptographique, ou tout ce qui donne accès à des fonds ou permet de révoquer des accès, préférez un e-mail chiffré de bout en bout avec PGP, ou une remise en main propre.

Miroir des sources : gitlab.erseni.net/open-source/secrets-component

Build déployé : page d'état

security.txt : /.well-known/security.txt

Vous n'êtes pas obligé de nous croire sur parole quant au JavaScript que vous exécutez. Voici la chaîne concrète que vous pouvez suivre.

1. Ouvrez le manifeste de build. Il indique le commit de l'application, celui du composant, celui du miroir, ainsi que le SHA-256 de chaque ressource livrée au navigateur. /build-manifest.json
2. Cliquez sur le commit du miroir. Il ouvre, sur le miroir public, la source exacte publiée avec ce déploiement.
3. Ouvrez les outils de développement, copiez l'URL du script secrets, récupérez-le et calculez son empreinte. Le résultat doit correspondre au champ browserJs.sha256 du manifeste. curl -s '<script src from DevTools>' | sha256sum
4. Lisez le fichier sur le miroir. La cryptographie du navigateur tient sur un écran et n'utilise que WebCrypto natif.

Pourquoi comparer les empreintes à la main alors que la balise script porte déjà un attribut Subresource Integrity (SRI) ? SRI fait rejeter par le navigateur un bundle qui ne correspond pas à l'empreinte présente dans le HTML, mais les deux proviennent du même déploiement : un serveur compromis livre simplement un nouveau couple. L'empreinte du manifeste provient du même serveur et partage cette limite. C'est le miroir public qui rend la vérification indépendante : il s'agit d'un système distinct dont l'historique est visible publiquement, comparez donc les valeurs du manifeste au commit du miroir et lisez-y le code source. Les scripts des composants web, les bibliothèques tierces et les feuilles de style ne portent aujourd'hui aucune empreinte SRI.