Mots de passe dans Slack : risques et alternatives sûres

Partager des mots de passe dans Slack est un risque de sécurité, parce que Slack conserve les messages indéfiniment, les rend consultables par recherche pour les admins du workspace et les expose aux intégrations d'applications tierces. Utilise plutôt des liens autodestructeurs chiffrés — des outils comme Vaulted chiffrent les identifiants dans ton navigateur avant que quoi que ce soit ne soit envoyé.

D'après le Verizon 2025 DBIR, 22 % des fuites de données avaient pour vecteur d'attaque initial des identifiants compromis. Et d'après une étude de Beyond Identity, plus de 41 % des employés ont déjà partagé des mots de passe professionnels — souvent via des canaux non sécurisés comme le chat et l'e-mail.

Ce qui arrive vraiment à ce mot de passe

Quand tu colles un identifiant dans Slack, il n'atteint pas seulement l'autre personne. Il devient une donnée que Slack stocke, indexe et conserve — souvent bien après que tu l'aies oublié.

Slack conserve les messages sur ses serveurs. Sur les forfaits payants, les admins du workspace peuvent configurer des politiques de rétention, mais beaucoup laissent le réglage par défaut : tout garder, pour toujours. Avec Enterprise Grid, les organisations peuvent exporter et fouiller l'historique complet de chaque message privé et de chaque canal — y compris les messages entre utilisateurs individuels.

Les messages Slack sont consultables par recherche. Quiconque dispose des bonnes permissions peut chercher des mots-clés dans tout le workspace. Dans la plupart des workspaces, une recherche sur « password » ou « API key » fera remonter des résultats qui feraient blêmir n'importe quel auditeur de sécurité.

Les applications tierces peuvent lire les messages. Toute application Slack disposant des bons scopes OAuth peut accéder à l'historique des messages. Ce bot de productivité que ton équipe a installé l'an dernier ? Il a peut-être un accès en lecture aux canaux et aux messages privés. Tu ne fais pas seulement confiance à la sécurité de Slack, mais aussi à celle de chaque intégration connectée à ton workspace.

Les messages survivent aux départs. Quand quelqu'un quitte l'entreprise, ses messages Slack restent. Ce message privé contenant le mot de passe de la base de données ? Il est toujours là, lisible par les admins, même après la désactivation du compte de la personne.

D'après le State of Secrets Sprawl Report 2025 de GitGuardian, 2,4 % des canaux Slack d'entreprise contenaient des secrets fuités — et le IBM Cost of a Data Breach Report 2025 a constaté que le coût moyen d'une fuite de données atteignait 4,44 millions de dollars à l'échelle mondiale.

Le problème de conformité

Si ton entreprise travaille vers une conformité SOC 2, ISO 27001 ou HIPAA, partager des identifiants dans Slack est un constat d'audit qui n'attend que de se produire.

Les auditeurs demandent précisément comment ton équipe transmet en interne les identifiants sensibles. « On les colle dans Slack » n'est pas la réponse qu'ils cherchent — et cela peut retarder ou bloquer ta certification.

Les SOC 2 Trust Services Criteria exigent des contrôles sur la façon dont les données sensibles sont transmises. Les liens autodestructeurs avec limite de consultations et chiffrement satisfont ce contrôle. Pas les messages Slack.

Ce qu'il faut faire à la place

La solution est simple : chiffre l'identifiant avant qu'il ne quitte ton appareil, puis partage un lien qui s'autodétruit après consultation.

Depuis ton navigateur

Va sur vaulted.fyi
Colle le mot de passe ou l'identifiant
Règle-le pour qu'il expire après 1 consultation
Envoie le lien dans Slack (ou ailleurs)

L'identifiant est chiffré avec AES-256-GCM dans ton navigateur grâce au chiffrement côté client. La clé de déchiffrement existe uniquement dans le URL fragment — elle n'atteint jamais le serveur. Une fois que ton collègue ouvre le lien, le secret est définitivement supprimé.

Désormais, quand quelqu'un cherche « password » dans Slack, il trouvera un lien mort au lieu d'un identifiant actif.

Depuis le terminal

Si tu vis dans la ligne de commande, le Vaulted CLI fait exactement la même chose :

npx vaulted-cli "staging-db-password" --views 1 --expires 1h

Mets-le dans un pipe, scripte-le, crée un alias. Le même chiffrement de bout en bout, les mêmes liens autodestructeurs.

Dans les workflows CI/CD

Tu partages des identifiants entre des workflows GitHub Actions ? La Vaulted GitHub Action s'en charge aussi :

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.DEPLOY_KEY }}
    views: 1
    expires: 1h

Règles rapides pour ton équipe

Ne colle jamais d'identifiants directement dans une application de chat — Slack, Teams, Discord, aucune d'entre elles
Utilise des liens autodestructeurs — Une consultation, expiration courte, toujours
Ajoute une phrase secrète pour les identifiants sensibles — Partage-la via un canal séparé (téléphone, en personne)
Renouvelle les identifiants après les avoir partagés — Traite chaque transmission comme une exposition potentielle
Définis une politique d'équipe — Fais du partage chiffré la norme, pas l'exception

Sur le moment, ce mot de passe dans Slack semble inoffensif. Mais il est consultable par recherche, permanent, et à une seule intégration mal configurée d'être exposé.

Partage-le de façon sécurisée à la place — ça prend les mêmes trois secondes.