Por qué compartir contraseñas en Slack y Microsoft Teams es un riesgo de seguridad (y qué hacer en su lugar)

"Oye, ¿me pasas la contraseña de la base de datos?" Y segundos después, una respuesta en Slack: "Claro, es Sup3rS3cr3t!2024".

Este intercambio ocurre miles de veces cada día en empresas de todos los tamaños. Se siente seguro porque Slack y Microsoft Teams son herramientas empresariales con autenticación, 2FA y cifrado HTTPS. Pero esta percepción es peligrosamente incorrecta.

Cuando pegas una contraseña en un mensaje de chat, no la estás enviando y listo. Estás creando un registro permanente, buscable y exportable que existirá en la infraestructura de la plataforma durante meses o años. Esta guía explica exactamente por qué esto es peligroso y qué hacer en su lugar.

Cómo Slack y Teams realmente almacenan tus mensajes

Para entender el riesgo, necesitas entender cómo estas plataformas manejan los datos internamente.

La arquitectura de datos de Slack

Slack almacena todos los mensajes en una base de datos centralizada. Cada mensaje es indexado para búsqueda, que es una de las funcionalidades principales de Slack. Cuando escribes una consulta de búsqueda, Slack escanea cada mensaje al que tienes acceso, incluyendo DMs, chats grupales y canales públicos y privados.

Datos clave sobre el manejo de datos de Slack:

• La retención por defecto es indefinida. A menos que un administrador configure explícitamente una política de retención, cada mensaje enviado se almacena para siempre.
• Los mensajes eliminados no se purgan inmediatamente. Cuando eliminas un mensaje, puede desaparecer de la interfaz pero persistir en los sistemas internos de Slack, copias de seguridad y exportaciones de cumplimiento.
• Las exportaciones de cumplimiento incluyen DMs. En los planes Enterprise Grid y Business+, los administradores pueden exportar todos los mensajes, incluyendo DMs privados, sin notificar a los participantes.
• Las integraciones de apps de terceros pueden acceder a mensajes. Las apps de Slack instaladas en un workspace pueden tener permisos para leer mensajes en canales, creando puntos adicionales de exposición.

La arquitectura de datos de Microsoft Teams

Microsoft Teams almacena mensajes en buzones de Exchange Online y usa infraestructura de Azure. Los mensajes se cifran en reposo usando BitLocker y cifrado de servicio, y en tránsito usando TLS. Sin embargo, Microsoft posee las claves de cifrado.

• eDiscovery y Content Search. Los administradores con los roles apropiados pueden buscar y exportar todos los mensajes de Teams, incluyendo chats privados, usando las herramientas de cumplimiento de Microsoft Purview.
• Las políticas de retención aplican. Los mensajes de Teams están sujetos a las políticas de retención de Microsoft 365, que a menudo por defecto retienen todo por razones de cumplimiento.
• Sin cifrado de extremo a extremo para chats estándar. Aunque Teams ofrece E2EE para llamadas VoIP 1:1, los mensajes de texto estándar no están cifrados de extremo a extremo. Microsoft y cualquier persona con acceso administrativo al tenant de Microsoft 365 pueden potencialmente leerlos.

6 riesgos de seguridad al compartir contraseñas en el chat

1. Historial persistente y buscable

Este es el riesgo más crítico. Las herramientas de chat corporativo están diseñadas para mantener el historial buscable. Esto significa que una contraseña que compartiste hace seis meses está a solo una consulta de búsqueda de distancia.

Si un atacante obtiene acceso a la cuenta de un solo empleado en Slack o Teams (mediante phishing, credential stuffing o robo de sesión), lo primero que hace es buscar palabras clave como:

• password, contraseña, clave
• API key, secret, token
• login, admin, root
• database, .env, credentials

Los investigadores de seguridad llaman a esto el "efecto mina de oro": una sola cuenta comprometida desbloquea años de credenciales compartidas en toda la organización.

2. Acceso administrativo y de cumplimiento

En muchas organizaciones, los administradores de TI, equipos legales y oficiales de cumplimiento tienen la capacidad de exportar y leer los logs de chat. Esto es por diseño: regulaciones como GDPR, HIPAA y SOC 2 a menudo requieren que las organizaciones retengan y puedan producir registros de comunicación.

Pero esto también significa que tu DM "privado" con una contraseña de base de datos podría ser legible por docenas de personas en tu organización con acceso administrativo. Y si cualquiera de esas cuentas de admin es comprometida, el atacante hereda ese acceso a todo.

3. Previsualizaciones de notificaciones y exposición de pantalla

Cuando alguien envía una contraseña en Slack o Teams, a menudo aparece como notificación push en el teléfono, tablet o pantalla de bloqueo del receptor. Las primeras palabras del mensaje son visibles para cualquiera cerca.

Esto es una mina de oro para ingeniería social. Un atacante realizando reconocimiento físico (shoulder surfing en un café, visita a la oficina, o incluso una foto de un escritorio) puede capturar credenciales que aparecen en una pantalla desbloqueada o previsualización de notificación.

4. Exposición de apps e integraciones de terceros

Slack y Teams tienen ecosistemas ricos de integraciones de terceros. Muchas organizaciones instalan apps para gestión de proyectos, CRM, monitoreo y más. Estas apps a menudo solicitan permisos para leer mensajes en canales.

Si cualquiera de estas apps de terceros tiene una vulnerabilidad de seguridad o es comprometida, los mensajes a los que tienen acceso, incluyendo cualquier contraseña compartida en esos canales, quedan expuestos.

5. Sin control de acceso granular en mensajes

Cuando envías una contraseña en un canal de Slack o chat de Teams, cada miembro puede verla. No hay forma de restringir un mensaje específico a una persona específica. Incluso en un DM, no puedes establecer una expiración, limitar las vistas o requerir autenticación adicional para leer el mensaje.

Compara esto con una herramienta diseñada para esto como los enlaces de un solo uso de Nurbak: puedes configurar el enlace para autodestruirse después de una vista, agregar una frase de paso para seguridad adicional y establecer un tiempo de expiración.

6. Riesgos de reenvío y capturas de pantalla

Una vez que una contraseña está en un mensaje de chat, cualquier participante puede reenviarla a otro canal, copiar-pegarla en otro lugar o hacer una captura de pantalla. No hay gestión de derechos digitales (DRM) en los mensajes de chat. La credencial ha dejado tu control permanentemente.

Escenarios de ataque reales

Estos no son riesgos teóricos. Son patrones de ataque documentados usados por actores de amenazas reales:

Escenario 1: Phishing que lleva a cosecha de credenciales

Un atacante envía un email de phishing convincente a un empleado. El empleado hace clic e ingresa sus credenciales de Slack. El atacante ahora tiene acceso a todo el historial de Slack del empleado. Busca "password", "API key" y "database" y encuentra credenciales compartidas durante el último año.

Escenario 2: Ex-empleado retiene acceso

Un empleado deja la empresa, pero su cuenta de Slack no se desactiva inmediatamente. O ya había descargado o capturado credenciales del chat. Retiene conocimiento de cada contraseña que fue compartida en Slack. Si esas credenciales no fueron rotadas, el ex-empleado aún tiene acceso.

Escenario 3: Bot de Slack comprometido

Un bot de Slack de terceros instalado para automatización de flujos de trabajo tiene una vulnerabilidad. Un atacante la explota y obtiene el token de acceso del bot, que tiene permiso para leer mensajes en varios canales. El atacante lee silenciosamente el historial del canal y extrae credenciales compartidas meses atrás.

El flujo de trabajo seguro: enlaces efímeros en lugar de mensajes de chat

La solución es simple: separar la comunicación de la transmisión de secretos. Usa Slack o Teams para decir "aquí está la credencial." Usa una herramienta diseñada para entregar la credencial real.

Paso a paso para compartir credenciales de forma segura

1. Ve a Nurbak y pega la credencial (contraseña, API key, variable de entorno, etc.).
2. Configura los ajustes de seguridad: configúralo para autodestruirse después de 1 vista, agrega una frase de paso opcional y elige un tiempo de expiración.
3. Copia el enlace generado y pégalo en Slack o Teams.
4. Tu compañero hace clic en el enlace, ve la credencial, y el enlace se destruye permanentemente.

Qué queda en el historial del chat: Un enlace muerto que retorna una página 404. Sin contraseña, sin API key, sin credencial. Si un atacante busca en los logs meses después, encuentra un cementerio de enlaces expirados, no una lista de contraseñas vivas.

Por qué este enfoque funciona

• Cifrado de conocimiento cero: Nurbak cifra la credencial en tu navegador usando AES-256 antes de que llegue a cualquier servidor. Ni siquiera Nurbak puede leer tus datos. Aprende más sobre cifrado del lado del cliente vs servidor.
• Enlaces autodestructivos: La credencial se elimina automáticamente después de ser vista. Sin persistencia, sin historial buscable.
• Rastro de auditoría sin exposición: Puedes verificar que el enlace fue accedido sin que la credencial se almacene en ningún lugar.
• Sin cambio de comportamiento requerido: Tu equipo sigue usando Slack o Teams para comunicarse. Solo pegan un enlace en lugar de una contraseña. El flujo agrega menos de 10 segundos.

¿Qué pasa con la función "Eliminar mensaje" de Slack?

Algunos equipos confían en eliminar el mensaje después de que el receptor lo ha visto. Esto es insuficiente por varias razones:

• Las exportaciones de cumplimiento de Slack pueden capturar el mensaje antes de que lo elimines.
• El mensaje puede persistir en los backups y sistemas internos de Slack.
• Las notificaciones push ya mostraron el contenido en potencialmente múltiples dispositivos.
• Cualquier app de terceros con acceso a mensajes puede haber cacheado el contenido.
• Depende de que los humanos recuerden eliminar, lo cual no es confiable.

Construyendo una cultura de compartir credenciales de forma segura

Las herramientas técnicas solas no son suficientes. Tu equipo necesita adoptar prácticas seguras como hábito:

• Establece una política: "Nunca pegues credenciales directamente en el chat. Siempre usa un enlace efímero."
• Lidera con el ejemplo: Cuando un compañero pida una contraseña en el chat, responde con un enlace de Nurbak en lugar de la credencial en texto plano.
• Usa herramientas que se integren con tu flujo de trabajo:La integración de Nurbak con Slack permite generar enlaces seguros directamente desde Slack.
• Rota credenciales que fueron compartidas previamente en chat: Si tu equipo ha estado compartiendo contraseñas en Slack o Teams, asume que esas credenciales están comprometidas.
• Audita regularmente el historial del chat: Busca periódicamente patrones de credenciales en tu historial y remedia los hallazgos. Aprende más sobre mejores prácticas de gestión de claves secretas.

Comparación: mensajes de chat vs. enlaces efímeros

Conclusión

Slack y Microsoft Teams son excelentes herramientas de comunicación. No son herramientas de gestión de credenciales. Cada contraseña pegada en un chat se convierte en un pasivo permanente, buscable y exportable que se vuelve más peligroso con el tiempo.

La solución es simple y toma segundos: usa un enlace cifrado y autodestructivo para cada credencial que compartas. Tu equipo sigue usando Slack y Teams para comunicarse. El único cambio es pegar un enlace en lugar de una contraseña.

Deja de tratar los logs de chat como una bóveda de contraseñas. Son archivos de texto buscables en el servidor de otra persona. Usa la herramienta correcta para el trabajo.