Uso compartido seguro
Cómo compartir un enlace privado de forma segura
Pasos prácticos para compartir un enlace de Collogue y su contraseña con menos exposición persistente.
Publicado: 4 de marzo de 2026
Límites de la implementación actual
Los enlaces actuales de Collogue llevan la carga cifrada en la URL. El navegador utiliza la Web Crypto API: PBKDF2-SHA-256 con 310.000 iteraciones deriva una clave AES-GCM de 256 bits a partir de la contraseña introducida por separado, con una sal aleatoria de 16 bytes y un IV de 12 bytes. El cliente actual no realiza ninguna solicitud a una API de aplicación para crear, recuperar o almacenar mensajes.
La contraseña no está codificada en el enlace. La implementación no ofrece visualización de un solo uso, eliminación en el servidor ni un temporizador de caducidad. Trate el enlace completo como sensible y comparta la contraseña por otro canal.
Contexto adicional
El cifrado protege el contenido bajo ciertas suposiciones técnicas. La entrega decide quién tiene la oportunidad de usarlo.
Un mensaje perfectamente cifrado enviado a la dirección equivocada sigue estando enviado a la dirección equivocada.
- compruebe la dirección completa de correo o el nombre de la cuenta;
- tenga cuidado con el autocompletado;
- confirme las solicitudes inusuales por un canal establecido;
- evite enviar a grupos amplios;
- no publique el enlace en un ticket o repositorio público.
Para credenciales importantes, contacte con el destinatario por un canal conocido en vez de responder sin comprobar una solicitud inesperada.
Suponga que envía acceso a un panel administrativo.
- el nombre de la empresa;
- la URL de inicio de sesión;
- el nombre de usuario;
- la contraseña;
- el propósito de la cuenta.
Un mensaje interceptado contiene un manual completo.
Un mensaje más limitado de Collogue podría contener solo la contraseña temporal. El canal ordinario puede proporcionar el contexto no sensible, o puede separar el contexto cuando el riesgo lo justifique.
No convierta esto en un ritual. Separar detalles inocuos aporta poco si todos los canales están controlados por la misma cuenta comprometida. Use su criterio.
La mejor contraseña que se puede entregar suele ser temporal y fácil de reemplazar.
- el enlace y la contraseña deben mantenerse privados;
- el destinatario solo debería abrirlo en un dispositivo de confianza;
- no debería enviarlo a un verificador de enlaces en línea;
- debería informar si el enlace o la contraseña no funcionan;
- la contraseña debería cambiarse después de usarla.
Evite la jerga técnica en los mensajes para usuarios. Explique que la contraseña se comparte por separado y que ambas partes deben mantenerse privadas.
Use el estado de confirmación del producto, pruebas automatizadas o un mensaje de muestra separado.
La interfaz debería mostrar esta advertencia antes de que el remitente abandone la pantalla de resultado.
El correo electrónico, los SMS, el chat de equipo y las llamadas tienen riesgos distintos.
- compromiso de la cuenta;
- dispositivos compartidos;
- conservación de mensajes;
- archivado corporativo;
- análisis de enlaces;
- vistas previas de notificaciones;
- comodidad del destinatario;
- posibilidad de verificar la identidad.
No existe un canal universalmente más seguro al margen de las personas y los sistemas implicados.
Para el uso empresarial normal, un canal establecido hacia un destinatario verificado y una credencial temporal suelen ser más valiosos que un proceso complejo que nadie sigue correctamente.
- escáneres públicos de URL;
- servicios genéricos de acortamiento;
- documentos públicos;
- redireccionadores de análisis;
- generadores de códigos QR en los que no confíe.
Esos servicios pueden recibir o solicitar la URL completa. Si la clave está dentro del enlace, pueden recibir la capacidad de abrir el mensaje.
El remitente puede enviar el enlace por correo y confirmar al destinatario por teléfono. Otro flujo puede enviar el contexto no secreto mediante un ticket y el enlace privado mediante un mensajero aprobado.
Esto puede hacer que el compromiso de un solo canal sea insuficiente.
No crea automáticamente una autenticación sólida. Si la misma persona controla ambos canales, si ambos se sincronizan con un dispositivo o si el remitente verifica a un atacante, la separación ofrece menos protección.
Use canales separados como un control más entre varios.
- reemplace las credenciales;
- no reenvíe el mismo secreto;
- confirme el destino;
- revise la actividad reciente de la cuenta;
- cree un enlace nuevo.
Envié la contraseña temporal mediante un enlace privado de Collogue. Use la contraseña que compartí por separado y cámbiela después de iniciar sesión por primera vez. Si cualquiera de las dos partes pudo llegar a otra persona, avíseme para que pueda reemplazar la credencial.
Este texto es breve, concreto y no promete una seguridad imposible.
Puede ser adecuado cuando el destinatario y la cuenta de correo son de confianza, el secreto es temporal y la organización entiende el comportamiento de los escáneres de enlaces. La entrega por correo no autentica por sí sola a quien ve el mensaje.
Para accesos de mayor riesgo, separar el contexto puede reducir el valor de un mensaje interceptado. No siempre es necesario y no sustituye a las credenciales temporales ni a MFA.
Puede hacerlo, pero tenga en cuenta la pertenencia a canales, la retención, los archivos empresariales, las vistas previas de notificaciones, el análisis de enlaces y el compromiso de la cuenta. Elija el destino adecuado más limitado.
Una frase adicional solo ayuda si es fuerte, se gestiona por separado y está correctamente implementada. Si puede entregarla de forma segura, valore el flujo completo en vez de suponer que otra contraseña siempre mejora la seguridad.
Cree un enlace privado de Collogue cuando necesite enviar una contraseña, un token, un código de recuperación u otro valor sensible breve.