Comment partager un mot de passe sans en laisser une copie derrière soi
La plupart des moyens que les gens utilisent chaque jour pour envoyer des mots de passe, e-mail, Slack, WhatsApp, même les SMS, en gardent discrètement une copie quelque part, pour toujours. Si votre objectif est réellement la confidentialité, il vous faut un canal qui s'autodétruit.
Un collègue vous demande le mot de passe de la base de données de préproduction : que faites-vous ? La plupart des gens l'envoient par l'application de chat qui est ouverte à ce moment-là : Slack, WhatsApp, iMessage, e-mail. Ça paraît anodin. Ça crée aussi un enregistrement permanent de l'identifiant à au moins trois endroits, et probablement davantage, selon la façon dont chacun a configuré ses appareils.
Cet article explique pourquoi c'est un problème, et ce qu'il faut faire à la place.
La carte des fuites
Quand vous collez un mot de passe dans une application de chat classique et que vous appuyez sur « envoyer », voici où des copies finissent généralement :
- Les serveurs du fournisseur. Slack, Google Workspace, Microsoft, Apple et Meta stockent tous les messages sur leur infrastructure. Même quand le transport est chiffré, l'entreprise peut lire le contenu (à quelques exceptions près, comme iMessage ou WhatsApp qui sont chiffrés de bout en bout).
- L'historique des messages sur les deux appareils. Indéfiniment, sauf si quelqu'un supprime manuellement, et même dans ce cas, souvent uniquement en local.
- La synchronisation cloud de ces appareils. Messages iCloud, sauvegardes Google Drive, archives Slack Enterprise. Le mot de passe se trouve maintenant aussi dans le stockage d'une autre entreprise.
- Les systèmes de notification. Les notifications push affichent souvent le corps du message sur l'écran de verrouillage. Elles transitent, et sont journalisées, par le service de notifications push d'Apple ou par Firebase Cloud Messaging.
- Les outils de sécurité des postes de travail. Si l'un de vous utilise un ordinateur professionnel géré par l'entreprise, les outils de DLP et de journalisation ont peut-être capturé le corps du message.
- Les captures d'écran et le copier-coller. Si votre collègue copie le mot de passe, il reste dans son presse-papiers, éventuellement synchronisé via le presse-papiers universel d'Apple ou l'historique du presse-papiers de Windows. S'il fait une capture d'écran, cette image se trouve maintenant dans sa photothèque, peut-être synchronisée dans le cloud.
Voilà la situation pour un simple message « tiens, voici le mot de passe ». L'identifiant existe à peut-être dix endroits, détenus par quatre entreprises différentes, indéfiniment.
À quoi ressemble vraiment un « bon » partage
Un transfert d'identifiant sûr possède trois propriétés :
- Éphémère. Le support du secret s'autodétruit après une seule lecture, ou après une courte fenêtre de temps. Il n'y a aucune archive qui puisse fuiter.
- Chiffré de bout en bout. Même l'entreprise qui fournit le transport ne peut pas voir le secret. Elle stocke tout au plus du texte chiffré.
- Vérification hors bande. Ce qui permet de déchiffrer le secret voyage par un canal différent de celui du blob chiffré, si bien qu'un seul canal compromis ne peut pas tout révéler.
La plupart des outils de « partage sécurisé de mot de passe » couvrent (1) et (2). Peu font (3) par défaut, alors que c'est le point le plus important pour les identifiants de grande valeur.
Les options, classées
1. Le dire au téléphone (ou en personne)
Ça paraît idiot. C'est pourtant l'une des options les plus sûres pour un partage ponctuel. Les appels téléphoniques ne sont pas archivés par défaut, ni d'un côté ni de l'autre, et une ligne vocale est bien plus difficile à aspirer qu'un message texte. L'inconvénient, c'est que les longues chaînes aléatoires sont pénibles à dicter. Réservez cette méthode aux secrets courts, pas aux clés API de 32 caractères.
2. La fonction de partage d'un gestionnaire de mots de passe
1Password, Bitwarden et Dashlane proposent tous un partage par lien à usage unique. Ça fonctionne bien, le lien expire après un clic ou après un délai défini, et dans certains cas le destinataire n'a pas besoin de compte. Le hic : l'expéditeur, au minimum, doit avoir un compte, l'entreprise voit les métadonnées (qui a envoyé quoi à qui et quand), et les destinataires butent parfois sur le parcours de réception.
3. Un lien chiffré éphémère
Des outils comme Btwinus, OneTimeSecret et PrivateBin permettent de créer un lien qui contient le secret chiffré et s'autodétruit après une lecture. Btwinus va plus loin en exigeant une phrase secrète que le lien ne contient pas, ce qui signifie que même si quelqu'un intercepte le lien, il ne peut pas le déchiffrer sans la seconde pièce, que vous envoyez par un autre canal (un appel téléphonique, une autre application de chat, en personne).
Cette séparation en deux canaux compte plus qu'on ne le pense. Si votre Slack est compromis et que vous avez envoyé à la fois le mot de passe et le lien par Slack, l'attaquant possède les deux moitiés. Si le lien passe par Slack et la phrase secrète par un appel téléphonique, l'attaquant doit compromettre deux choses différentes pour obtenir l'identifiant. (C'est le même modèle de chiffrement dans un lien que Btwinus utilise pour le chat.)
4. Les messages éphémères de Signal
Signal prend en charge les messages qui se suppriment automatiquement après un délai défini. Chiffré de bout en bout, aucune rétention sur serveur. Vraiment solide. La friction, c'est que les deux parties doivent avoir un compte Signal et s'être déjà ajoutées mutuellement, parfait pour une relation durable, pénible pour un transfert ponctuel avec quelqu'un que vous n'avez pas déjà sur Signal. (Pour une analyse plus complète, voir comment Signal, Telegram et Btwinus se comparent en matière d'anonymat.)
5. L'e-mail chiffré avec PGP
Inattaquable si les deux côtés l'ont configuré. Presque personne ne l'a fait. À éviter, sauf si vous évoluez déjà dans une communauté qui utilise PGP.
Que faire concrètement, selon la situation
Envoyer le mot de passe de la base de préproduction à un collègue qui en a besoin pendant une heure : lien chiffré éphémère avec une phrase secrète envoyée par un canal séparé. Btwinus, OneTimeSecret, ou la fonction de partage de votre gestionnaire de mots de passe.
Envoyer une clé API à un prestataire pour une intégration de longue durée : un coffre-fort partagé dans un gestionnaire de mots de passe. L'identifiant doit vivre à un endroit où les deux équipes peuvent le renouveler ; les transferts à usage unique ne correspondent pas à ce flux de travail.
Envoyer un code de récupération à un membre de la famille : appel téléphonique ou en personne. L'identifiant est court, la relation est durable, et le secret n'a pas besoin de vivre ailleurs que dans vos têtes.
Envoyer une phrase de récupération de portefeuille crypto : jamais, au grand jamais, par voie numérique. Écrivez-la sur papier et remettez-la en main propre. Tout le reste est une erreur.
Le principe, en résumé
La question n'est pas « cette application est-elle chiffrée ? », la plupart des applications modernes le sont. La question, c'est : une fois ce mot de passe envoyé, où en existe-t-il encore une copie, et qui contrôle ces endroits ? Si la réponse est « cinq serveurs, indéfiniment, détenus par des gens que je ne connais pas », vous avez utilisé le mauvais outil.
Utilisez un outil qui s'autodétruit. Répartissez le secret sur deux canaux quand ça compte. Et pour ce qui est vraiment sensible, ne l'envoyez pas du tout par voie numérique.
Besoin de partager un mot de passe tout de suite, sans laisser de trace ? Btwinus est conçu exactement pour ça, lien chiffré, phrase secrète par un canal séparé, rien de stocké.
Démarrer un chat privé →