Sécurité et confiance

• Votre navigateur chiffre localement.
• Notre serveur ne stocke que du texte chiffré.
• 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. La rétention WAL au niveau de la base s'applique jusqu'à sa rotation. 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. 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 de cette plage. 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, 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. Il n'existe pas encore d'empreinte Subresource Integrity pour le bundle principal.
• 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é.
• 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 pas d'attribut Subresource Integrity (SRI) sur la balise script ? SRI ferait rejeter automatiquement par le navigateur un bundle altéré, mais il impose de recalculer et de redéployer les empreintes d'intégrité à chaque modification et s'accommode mal des variantes A/B. L'empreinte du manifeste n'offre pas la même application automatique par le navigateur que SRI. Elle donne aux relecteurs et aux personnes qui auto-hébergent une valeur SHA-256 concrète à comparer au bundle navigateur effectivement servi.