Partage sécurisé
Partager un lien privé en toute sécurité
Des étapes pratiques pour partager un lien Collogue et son mot de passe avec moins d’exposition persistante.
Publié le: 4 mars 2026
Limites de l’implémentation actuelle
Les liens Collogue actuels portent la charge utile chiffrée dans l’URL. Le navigateur utilise l’API Web Crypto : PBKDF2-SHA-256 avec 310 000 itérations dérive une clé AES-GCM de 256 bits à partir du mot de passe saisi séparément, avec un sel aléatoire de 16 octets et un IV de 12 octets. Le client actuel n’envoie aucune requête à une API applicative pour créer, récupérer ou stocker des messages.
Le mot de passe n’est pas encodé dans le lien. L’implémentation ne fournit ni affichage à usage unique, ni suppression côté serveur, ni minuteur d’expiration. Considérez le lien complet comme sensible et transmettez le mot de passe par un autre canal.
Contexte complémentaire
Le chiffrement protège le contenu selon certaines hypothèses techniques. La distribution décide qui a la possibilité de l’utiliser.
Un message parfaitement chiffré envoyé à la mauvaise adresse reste envoyé à la mauvaise adresse.
- vérifiez l’adresse e-mail complète ou le nom du compte ;
- soyez prudent avec la saisie automatique ;
- confirmez les demandes inhabituelles par un canal établi ;
- évitez les envois à de grands groupes ;
- ne publiez pas le lien dans un ticket ou un dépôt public.
Pour des identifiants importants, contactez le destinataire par un canal connu au lieu de répondre aveuglément à une demande inattendue.
Supposons que vous envoyiez l’accès à un panneau d’administration.
- le nom de l’entreprise ;
- l’URL de connexion ;
- le nom d’utilisateur ;
- le mot de passe ;
- l’objectif du compte.
Un message intercepté fournit un mode d’emploi complet.
Un message Collogue plus limité pourrait ne contenir que le mot de passe temporaire. Le canal ordinaire peut fournir le contexte non sensible, ou ce contexte peut être séparé si le risque le justifie.
N’en faites pas un rituel. Séparer des détails inoffensifs a peu de valeur si tous les canaux sont contrôlés par le même compte compromis. Faites preuve de discernement.
Le meilleur mot de passe à transmettre est souvent temporaire et facile à remplacer.
- le lien et le mot de passe doivent rester privés ;
- le destinataire ne devrait l’ouvrir que sur un appareil de confiance ;
- il ne devrait pas l’envoyer à un vérificateur de liens en ligne ;
- il devrait signaler un lien ou un mot de passe qui ne fonctionne pas ;
- un mot de passe devrait être changé après utilisation.
Évitez le jargon technique dans les messages destinés aux utilisateurs. Expliquez que le mot de passe est transmis séparément et que les deux éléments doivent rester privés.
Utilisez l’état de confirmation du produit, des tests automatisés ou un message d’exemple distinct.
L’interface doit afficher cet avertissement avant que l’expéditeur ne quitte l’écran de résultat.
Les e-mails, les SMS, les chats d’équipe et les appels téléphoniques présentent des risques différents.
- compromission du compte ;
- partage de l’appareil ;
- conservation des messages ;
- archivage d’entreprise ;
- analyse des liens ;
- aperçu des notifications ;
- commodité du destinataire ;
- possibilité de vérifier l’identité.
Il n’existe pas de canal universellement plus sûr indépendamment des personnes et des systèmes concernés.
Pour un usage professionnel courant, un canal établi vers un destinataire vérifié et un identifiant temporaire sont souvent plus utiles qu’une procédure complexe que personne ne suit correctement.
- analyseurs d’URL publics ;
- services génériques de raccourcissement ;
- documents publics ;
- redirections d’analyse ;
- générateurs de QR codes auxquels vous ne faites pas confiance.
Ces services peuvent recevoir ou demander l’URL complète. Si la clé se trouve dans le lien, ils peuvent recevoir la capacité d’ouvrir le message.
Un expéditeur peut envoyer le lien par e-mail et confirmer le destinataire par téléphone. Un autre flux peut envoyer le contexte non secret par un ticket et le lien privé par une messagerie approuvée.
Cela peut rendre une compromission d’un seul canal moins suffisante.
Cela ne crée pas automatiquement une authentification forte. Si la même personne contrôle les deux canaux, si les deux sont synchronisés sur un même appareil ou si l’expéditeur vérifie un attaquant, la séparation apporte moins.
Utilisez les canaux séparés comme une mesure parmi d’autres.
- remplacez les identifiants ;
- ne renvoyez pas le même secret ;
- confirmez la destination ;
- examinez l’activité récente du compte ;
- créez un nouveau lien.
J’ai envoyé le mot de passe temporaire par un lien privé Collogue. Utilisez le mot de passe transmis séparément et changez-le après votre première connexion. Si l’un des deux éléments a pu parvenir à quelqu’un d’autre, prévenez-moi afin que je remplace l’identifiant.
Ce texte est court, précis et ne promet pas une sécurité impossible.
Il peut convenir lorsque le destinataire et le compte e-mail sont fiables, que le secret est temporaire et que l’organisation comprend le comportement des analyseurs de liens. La distribution par e-mail n’authentifie pas à elle seule la personne qui consulte.
Pour un accès plus risqué, séparer le contexte peut réduire la valeur d’un message intercepté. Ce n’est pas toujours nécessaire et cela ne remplace ni les identifiants temporaires ni le MFA.
Vous pouvez, mais tenez compte de l’appartenance aux canaux, de la conservation, des archives d’entreprise, des aperçus de notifications, de l’analyse des liens et de la compromission des comptes. Choisissez la destination la plus étroite qui convient.
Une phrase secrète supplémentaire peut aider seulement si elle est forte, gérée séparément et correctement implémentée. Si vous pouvez la transmettre de façon sûre, évaluez le flux complet au lieu de supposer qu’un mot de passe supplémentaire améliore toujours la sécurité.
Créez un lien privé Collogue pour envoyer un mot de passe, un jeton, un code de récupération ou une autre valeur sensible courte.