Partager des mots de passe et des secrets par mail de façon sécurisée
Envoyer un mot de passe par mail reste risqué. Avec Yopass, on transmet un lien à usage unique, chiffré et expirant, au lieu de laisser le secret dans la boîte mail.
Envoyer un mot de passe par mail est encore un réflexe courant. Un accès temporaire, un compte prestataire, un identifiant de console, une clé API copiée rapidement dans un message: tout le monde sait que ce n’est pas idéal, mais beaucoup d’équipes continuent parce que c’est simple.
Le problème, c’est que le mail n’est pas un coffre-fort. Il est copié, indexé, synchronisé sur plusieurs appareils, parfois transféré, parfois conservé pendant des années. Si une boîte mail est compromise dans six mois, les secrets envoyés aujourd’hui peuvent encore être retrouvés.
C’est précisément le risque qu’un outil comme Yopass permet de réduire: au lieu d’envoyer le secret dans le mail, on envoie un lien temporaire, idéalement à usage unique, avec une expiration.
Le vrai problème: le secret reste dans la boîte mail
Quand un mot de passe est écrit directement dans un mail, il devient très difficile à contrôler.
Il peut rester présent dans:
- la boîte d’envoi de l’expéditeur;
- la boîte de réception du destinataire;
- les sauvegardes mail;
- les clients mail synchronisés;
- les recherches internes;
- les transferts ou réponses de conversation;
- les outils de support ou de ticketing connectés à la messagerie.
Le risque n’est donc pas seulement l’interception au moment de l’envoi. Le risque, plus banal et souvent plus dangereux, est la réutilisation différée: quelqu’un accède plus tard à une boîte mail, recherche des mots comme “mot de passe”, “admin”, “accès”, “VPN” ou “root”, puis récupère des identifiants encore valides.
Une bonne pratique consiste donc à ne pas laisser le secret durablement dans le canal de discussion.
Yopass: partager un secret sans le laisser traîner dans le mail
Yopass est une solution open source conçue pour partager rapidement des secrets: mots de passe, clés, tokens, informations sensibles ponctuelles.
Son principe est simple:
- vous collez le secret dans l’interface Yopass;
- le secret est chiffré côté navigateur;
- Yopass génère un lien de consultation;
- vous envoyez ce lien par mail, ticket ou messagerie;
- le destinataire ouvre le lien pour récupérer le secret;
- le secret expire automatiquement, et peut être configuré pour n’être lisible qu’une seule fois.
L’intérêt est très concret: si le mail est compromis plus tard, l’attaquant ne retrouve pas directement le mot de passe. Il retrouve au mieux un lien expiré ou déjà consommé.
Ce n’est pas une magie qui rend tous les échanges invulnérables. C’est une réduction pragmatique d’un risque très fréquent.
Le lien à usage unique change le scénario d’attaque
Un lien à usage unique apporte une propriété utile: une fois le secret consulté, il ne peut plus être relu via le même lien.
Cela change beaucoup de choses dans la vraie vie.
Si un mot de passe est envoyé en clair par mail, il reste exploitable tant que le mot de passe n’a pas été changé. Si le même mot de passe est transmis via un lien Yopass à usage unique, le mail ne contient pas le secret lui-même. Après consultation, le lien ne permet plus de récupérer l’information.
En cas de compromission ultérieure de la messagerie, l’attaquant ne peut donc pas simplement fouiller l’historique et réutiliser les secrets passés.
C’est particulièrement utile pour:
- un accès initial à un serveur;
- un mot de passe temporaire;
- une clé API transmise ponctuellement;
- un secret de déploiement;
- un accès prestataire;
- un code de récupération;
- une information sensible partagée entre équipes techniques et métier.
La logique est saine: le mail transporte le contexte, pas le secret durable.
L’expiration limite la durée d’exposition
L’autre brique importante est l’expiration.
Un secret partagé n’a généralement pas besoin de rester disponible pendant des semaines. Pour un échange opérationnel, une expiration courte suffit souvent: une heure, une journée, parfois une semaine selon le contexte.
Cette durée doit être choisie en fonction du risque:
- court délai pour un mot de passe administrateur ou un accès critique;
- délai un peu plus long si le destinataire n’est pas disponible immédiatement;
- expiration stricte pour les accès temporaires ou les secrets très sensibles.
L’objectif n’est pas de créer une contrainte inutile. L’objectif est d’éviter qu’un secret ponctuel devienne une dette de sécurité permanente.
Pourquoi nous recommandons plutôt l’auto-hébergement
Il existe une instance publique de démonstration, yopass.se, pratique pour comprendre le fonctionnement ou tester rapidement l’outil.
Pour un usage professionnel, nous recommandons toutefois d’héberger sa propre instance Yopass.
La raison est simple: quand on parle de mots de passe, de secrets et de processus internes, la maîtrise de l’instance compte autant que l’outil lui-même.
L’auto-hébergement permet de contrôler:
- l’emplacement de l’hébergement;
- l’accès réseau à l’interface;
- la configuration des expirations;
- les journaux et leur rétention;
- les sauvegardes de la configuration;
- les mises à jour;
- l’intégration éventuelle à vos procédures internes;
- le niveau de conformité attendu par votre organisation.
C’est cohérent avec notre approche habituelle: privilégier des briques open source, maîtrisées, exploitables et réversibles plutôt que de dépendre d’un service externe pour un sujet sensible.
Ce que Yopass ne règle pas à lui seul
Yopass est utile, mais il ne remplace pas une vraie hygiène de gestion des accès.
Il faut garder quelques limites en tête.
D’abord, Yopass sert à transmettre un secret, pas à le stocker durablement. Pour gérer des mots de passe d’équipe, des coffres partagés, des droits et des rotations, il faut un gestionnaire de mots de passe adapté.
Ensuite, le contexte ne doit pas donner trop d’informations dans le mail. Évitez par exemple d’envoyer dans le même message: le lien, le nom exact du service, l’identifiant, l’URL d’administration et une phrase qui explique tout. Quand le risque est élevé, mieux vaut séparer les canaux: le lien d’un côté, le contexte de l’autre.
Enfin, un secret récupéré doit rester bien géré après transmission: changement au premier usage si nécessaire, rotation, suppression des accès temporaires, contrôle des permissions.
L’outil améliore le processus, mais il ne dispense pas de la discipline opérationnelle.
Une bonne pratique simple à intégrer dans les process
L’intérêt de Yopass est aussi culturel. Il rend la bonne pratique suffisamment simple pour être adoptée.
Dire à une équipe “n’envoyez jamais de mot de passe par mail” ne suffit pas. Si on ne fournit pas d’alternative pratique, les anciens réflexes reviennent dès qu’il y a de l’urgence.
Avec une instance Yopass interne, la règle devient beaucoup plus facile à appliquer:
- le secret ne part jamais directement dans le mail;
- le lien expire vite;
- le lien est à usage unique quand c’est possible;
- le contexte sensible est limité ou transmis séparément;
- les secrets temporaires sont changés ou supprimés après usage.
C’est exactement le type de petit outil qui améliore la sécurité sans ralentir inutilement les équipes.
Le type d’outil que nous mettons à disposition de nos clients
Chez Forget About IT, nous ne voyons pas la sécurité comme une collection de grands principes abstraits. Elle doit se traduire dans les gestes quotidiens: comment on partage un accès, comment on suit une CVE, comment on restaure une sauvegarde, comment on documente une intervention, comment on réduit les angles morts.
Yopass fait partie de ces outils simples qui changent les habitudes au bon endroit.
Dans nos missions d’infogérance et de renfort technique, nous pouvons mettre ce type de solution à disposition de nos clients, l’héberger proprement, l’intégrer à leurs usages et accompagner les équipes pour que la bonne pratique devienne naturelle.
Ce n’est pas spectaculaire. C’est même plutôt sobre. Mais en sécurité opérationnelle, les meilleurs progrès viennent souvent de là: des process plus propres, des outils maîtrisés, et moins de secrets qui traînent là où ils ne devraient pas.
Conclusion
Partager un mot de passe par mail en clair est une mauvaise habitude parce que le secret reste durablement dans un canal qui n’a pas été conçu pour cela.
Avec Yopass, on remplace cette logique par un mécanisme plus sain: un secret chiffré, un lien temporaire, une lecture unique quand c’est possible, et une expiration qui limite la fenêtre d’exposition.
Pour tester le principe, l’instance publique yopass.se permet de comprendre rapidement l’usage. Pour une entreprise, nous recommandons plutôt de partir sur une instance auto-hébergée, maîtrisée et intégrée à ses propres règles d’exploitation.
- Voir le projet Yopass sur GitHub
- Découvrir notre offre d’infogérance
- Nous contacter pour améliorer vos pratiques de sécurité
FAQ: partager des mots de passe avec Yopass
Peut-on envoyer un mot de passe par mail de façon sécurisée ?
Il vaut mieux éviter d’envoyer le mot de passe directement dans le corps du mail. Une solution comme Yopass permet de transmettre un lien temporaire, à usage unique, afin de réduire le risque si la boîte mail est compromise plus tard.
Qu’est-ce que Yopass ?
Yopass est un outil open source de partage de secrets. Il chiffre le secret côté navigateur, génère un lien de consultation et permet de limiter l’accès dans le temps et, selon la configuration, à une seule lecture.
Pourquoi auto-héberger Yopass ?
L’auto-hébergement permet de maîtriser l’instance, les journaux, la politique de rétention, l’accès réseau, les sauvegardes et le cadre de conformité. C’est l’approche que nous recommandons pour un usage professionnel.
Yopass remplace-t-il un gestionnaire de mots de passe ?
Non. Yopass sert à transmettre ponctuellement un secret. Pour stocker, organiser et partager durablement des identifiants, il faut un gestionnaire de mots de passe adapté.
Forget About IT peut-il mettre ce type d’outil en place ?
Oui. Nous mettons ce type de solution à disposition de nos clients lorsque cela améliore leurs processus, leur sécurité opérationnelle et leurs bonnes pratiques au quotidien.
Articles recommandés
Sécurité
CVE-2026-31431 / Copy Fail: une faille Linux majeure permettant une élévation discrète en root
Dans le cadre de notre veille sécurité, nous signalons CVE-2026-31431, alias Copy Fail, une faille Linux locale critique pouvant permettre une élévation de privilèges en root sur de très nombreux environnements.
Sécurité
Scaleway remplace Microsoft sur la plateforme des données de santé: un signal fort pour la souveraineté
Le choix de Scaleway pour héberger la Plateforme des données de santé marque un tournant concret pour la souveraineté numérique, la sécurité juridique et la maîtrise des infrastructures sensibles.
Sécurité
Protection anti-DDoS: pourquoi Cloudflare doit être piloté, pas seulement activé
Une protection anti-DDoS efficace ne consiste pas seulement à placer Cloudflare devant un site: il faut comprendre le trafic, ajuster les règles WAF et organiser la réaction en cas d'attaque.