Fini les mots de passe clients qui s'accumulent dans votre boîte mail.
Demandez mots de passe, clés d'API et identifiants via un lien à usage unique, chiffré de bout en bout. Le serveur ne voit jamais le texte en clair.
Chiffré localement dans votre navigateur Lecture unique Sans compte Open source
Arrêtez de demander à vos clients d'envoyer leurs mots de passe par e-mail.
Trois façons dont Vault remplace les transmissions risquées que vous faites chaque semaine.
Demander des identifiants en toute sécurité
Générez un lien de demande à usage unique. Votre interlocuteur chiffre le secret avec une paire de clés qui n'existe que dans votre navigateur. Vous recevez du texte chiffré, jamais un mot de passe par e-mail.
Partager des secrets via un lien à usage unique
Chiffrez dans votre navigateur, partagez un lien qui s'autodétruit. La première lecture supprime définitivement le secret côté serveur. Aucune copie ne traîne dans les boîtes mail ni dans l'historique des conversations.
Vérifier le code et le déploiement
Chaque ligne de cryptographie est publiée sous AGPL-3.0 sur un miroir public. La page d'état expose le SHA du commit déployé ainsi que le SHA-256 du bundle navigateur, que vous pouvez recalculer vous-même.
Le chiffrement et le déchiffrement se font dans votre navigateur via l'API WebCrypto native. La clé vit dans le fragment de l'URL et ne nous parvient jamais.
Structurellement, il n'existe aucun texte en clair que nous puissions divulguer, remettre sur réquisition ou perdre.
AES-256 Chiffrement authentifié GCM
X25519 Échange de clés par demande
0 Octet de texte en clair sur le serveur
Demandez un secret sans jamais le voir en clair
C'est le flux de demande qui distingue Vault. Ne demandez plus à vos clients de vous envoyer leurs mots de passe par e-mail ou sur Slack.
Créez la demande
Votre navigateur génère localement une paire de clés X25519. La clé privée ne quitte jamais votre appareil.
Partagez le lien de demande
Envoyez le lien à la personne qui détient les identifiants. E-mail, messagerie, ou même sur papier : le serveur ne voit jamais la clé.
Elle transmet le secret
Son navigateur chiffre le secret avec votre clé publique et n'envoie que du texte chiffré.
Vous le récupérez chiffré
Ouvrez votre lien de récupération. Votre navigateur déchiffre localement. Exposition du texte en clair côté serveur : zéro.
À quoi ça ressemble
Trois étapes. Aucun compte. Aucun texte en clair sur le serveur.
Conçu pour les vraies transmissions d'identifiants
Le flux qui protège un mot de passe ponctuel protège aussi chaque transmission d'identifiants récurrente de votre quotidien.
Les agences qui collectent les accès de leurs clients
Envoyez un seul lien de demande au lieu de relancer le client sur trois fils d'e-mails. Rien n'atterrit en clair dans votre boîte mail.
Les développeurs qui partagent des clés d'API
Transmettez une clé Stripe, un PAT GitHub ou un identifiant AWS sans en laisser de copie dans Slack ou dans l'historique Git.
Le support qui reçoit des données sensibles
Vos clients envoient codes de secours 2FA, pièces d'identité ou phrases de récupération via un lien à usage unique plutôt que par ticket.
Les indépendants qui intègrent de nouveaux clients
Collectez les accès aux systèmes historiques que votre client ne peut pas passer en SSO. Chiffré dans son navigateur, déchiffré dans le vôtre.
Les accès temporaires en DevOps
Transmettez à un collègue un accès de production éphémère pendant un incident. Le lien expire, aucun nettoyage oublié.
Les équipes internes qui partagent des secrets
Ne collez plus de mots de passe dans des documents partagés. Un lien à usage unique, supprimé définitivement après la première lecture, compatible avec vos exigences d'audit.
La première lecture réussie supprime définitivement le secret côté serveur, avant même que la réponse ne quitte la machine. Aucune copie ne traîne dans les boîtes mail, l'historique des conversations ou les sauvegardes.
Rouvrez le même lien et vous n'obtiendrez qu'un « expiré ».
Construit à ciel ouvert, vérifiable de bout en bout
Six propriétés que nous nous imposons. Chacune est vérifiable dans le code source public.
Zero-knowledge par conception
Le serveur ne stocke que du texte chiffré. La clé de déchiffrement vit dans le fragment de l'URL et ne nous parvient jamais.
Chiffrement côté navigateur
AES-GCM-256 et X25519 s'exécutent via l'API WebCrypto native du navigateur. Aucune bibliothèque cryptographique tierce, aucun texte en clair sur le réseau.
Séparation de la clé dans le fragment d'URL
Les navigateurs n'envoient jamais la partie située après le # dans les requêtes HTTP. Nous y plaçons la clé volontairement, afin que le serveur soit structurellement incapable de la voir.
Open source, miroir public
Chaque ligne qui traite votre secret est sous licence AGPL-3.0 et publiée sur un miroir GitLab public. Lisez-la, forkez-la, hébergez-la vous-même.
Vérification du build déployé
La page d'état expose le commit de l'application, celui du composant, celui du miroir et le SHA-256 du bundle livré à votre navigateur.
Limites documentées
Nous listons ce contre quoi cette architecture ne protège pas, y compris le risque lié à la livraison du JavaScript et la fuite de métadonnées. Aucune promesse de sécurité absolue.
Pourquoi ne pas simplement utiliser Password Pusher, PrivateBin ou Bitwarden Send ?
Sur la base de la documentation publique et du code source à la date de publication. Chaque outil optimise pour un modèle de menace différent. Cette comparaison porte sur la transmission d'identifiants à usage unique depuis le navigateur.
| Fonctionnalité | Erseni Vault | Password Pusher | PrivateBin | Bitwarden Send |
|---|---|---|---|---|
| Zero-knowledge (le serveur ne voit jamais le texte en clair) | Oui | Non | Oui | Oui |
| Demandes d'identifiants zero-knowledge (le serveur ne voit jamais la réponse) | Oui | Non | Non | Non |
| Open source | Oui | Oui | Oui | Partiel |
| Auto-hébergeable | Oui | Oui | Oui | Oui |
| Aucun compte requis | Oui | Oui | Oui | Non |
Sources
Chaque affirmation est vérifiable auprès de la source liée du concurrent. Si une valeur n'est plus à jour, ouvrez un ticket sur le miroir public et nous corrigerons le tableau.
Password Pusher (GitHub) Chiffrement côté serveur avec une clé détenue par le serveur ; pas de zero-knowledge par conception. Propose une fonctionnalité de demandes entrantes, mais les envois utilisent la même clé détenue par le serveur : le flux de demande n'est donc pas zero-knowledge. Sous licence AGPL-3.0, auto-hébergeable, aucun compte requis.
PrivateBin (GitHub) Chiffrement AES-GCM dans le navigateur avec la clé dans le fragment de l'URL, le serveur ne stocke que du texte chiffré. Licence Zlib, auto-hébergeable, sans compte.
Bitwarden Send FAQ Chiffré côté serveur avec une clé dérivée du compte ; les destinataires utilisent un lien à usage unique. La fonctionnalité Send exige un compte expéditeur. Le serveur est sous AGPL-3.0 ; le client officiel et les applications sont distribués sous une licence propriétaire comportant des composants fermés, d'où la mention « partiel » pour l'open source.
Vérifiez notre code
La confiance se gagne par la vérifiabilité. Le backend et la cryptographie du navigateur sont publiés sous licence AGPL-3.0.
Code source : gitlab.erseni.net/open-source/secrets-component
Modèle de menace : docs/architecture.md
Build actuel : page d'état indique le SHA du commit déployé. Comparez-le au miroir public pour vérifier.
Tarifs
Utilisation gratuite, sans limite de volume. Aucun compte. Aucun traçage. Aucune publicité.
Business est disponible dès maintenant, et vous pouvez inviter des membres de votre équipe. Des questions ? Écrivez à hello@erseni.com.
Partagez votre prochain secret de la bonne façon
Aucun compte, aucun texte en clair, aucune trace. Chiffré de bout en bout dans votre navigateur et détruit à la première lecture.