Pasar contraseñas por WhatsApp, Slack o email: el hábito que nadie audita

El secreto vive para siempre en el canal

Cuando mandás una credencial por chat o email, dejás de controlar su ciclo de vida. Queda en el historial del emisor, del receptor y del servidor del proveedor, sujeta a las políticas de retención de la plataforma — que en la mayoría de los planes empresariales significa años, o para siempre. Queda indexada y buscable: cualquier persona que en el futuro tenga acceso a ese canal, ese hilo o esa casilla puede encontrarla con una búsqueda de dos palabras. Y queda incluida en exportaciones, backups y procesos de eDiscovery. Una contraseña que necesitabas compartir durante cinco minutos pasa a existir en múltiples copias, en infraestructura de terceros, por tiempo indefinido.

El modelo de amenaza real: la cuenta comprometida

El riesgo principal no es que alguien intercepte el mensaje en tránsito — el TLS de las plataformas cubre eso razonablemente. El riesgo es el acceso posterior al historial: una cuenta de correo comprometida por phishing, una sesión de Slack robada, un teléfono perdido con WhatsApp abierto, o un empleado desvinculado cuyo offboarding no cerró todos los accesos. En cualquiera de esos escenarios, el atacante no obtiene un mensaje: obtiene años de historial buscable. Y las credenciales encontradas ahí suelen seguir siendo válidas, porque nadie rota una contraseña por el solo hecho de haberla mandado por chat. El chat convierte cada compromiso de cuenta en un compromiso potencial de todos los secretos que pasaron por ella.

Por qué "la borro después de mandarla" no funciona

El borrado manual es el control que todos declaran y casi nadie ejecuta — y aunque se ejecute, es insuficiente. Borrar el mensaje del lado del emisor no garantiza el borrado en el dispositivo del receptor, en los backups de la plataforma ni en las notificaciones que ya se sincronizaron. En canales grupales, el alcance real del secreto es todo el grupo, incluyendo gente que se suma después si la plataforma muestra historial. Un control que depende de que un humano se acuerde de hacer algo, después de que la necesidad ya pasó, tiene una tasa de cumplimiento predeciblemente baja. La seguridad del secreto no puede depender de la disciplina posterior al envío: tiene que estar en el mecanismo de envío mismo.

Qué dice esto en una auditoría o un incidente

Para un equipo que responde cuestionarios de seguridad o audita contra ISO 27001, el manejo de secretos es pregunta obligada: cómo se comparten credenciales, quién accede, cómo se revocan. "Por Slack" no es una respuesta presentable, y los auditores lo saben buscar. Peor aún en un incidente: si una credencial filtrada apareció en el historial de chat, el análisis forense tiene que asumir que todo el historial accesible está comprometido, lo que multiplica el alcance de la investigación y de la notificación. El costo del hábito no se paga el día que mandás la contraseña — se paga el día que alguien tiene que reconstruir por dónde pasó.

Cómo cortar el hábito sin frenar al equipo

Prohibir sin dar alternativa no funciona: la necesidad de compartir accesos es real y la gente resuelve con lo que tiene. El cambio sostenible tiene tres piezas. Primero, un canal designado para secretos, tan fácil de usar como pegar el texto en el chat — si tiene más fricción que el chat, pierde. Segundo, una regla simple y comunicada: las credenciales viajan solo por ese canal, sin excepciones por urgencia. Tercero, higiene del stock existente: una búsqueda periódica de credenciales en los canales históricos, con rotación de todo lo que aparezca. La política sin herramienta es voluntarismo; la herramienta sin política es opcional. Juntas, convierten el camino seguro en el camino más corto.

Dale a tu equipo un canal seguro para las keys

ShaSafSec te permite compartir credenciales, API keys y secretos sin dejarlos viviendo en el historial de chats y correos. El camino seguro, con la misma facilidad que pegar y enviar.