Elido
10 min de lecturaFunciones

Enlaces cortos protegidos con contraseña: cuándo y cómo restringir uno

Qué es un enlace corto protegido con contraseña, los casos de uso que encajan, cómo funciona una puerta de contraseña en la redirección y los límites de seguridad que debes tener en cuenta

Marius Voß
DevRel · edge infra
Un enlace corto pasando por una puerta de contraseña antes de llegar a su destino, con una contraseña incorrecta bloqueada

Un enlace corto protegido con contraseña es una URL corta que pide una contraseña antes de redirigir a alguien. Abres el enlace, llegas a una pequeña página intermedia en lugar del destino, escribes la contraseña y solo entonces se activa la redirección. Escribe mal la contraseña y te quedas en la solicitud. El destino nunca queda expuesto hasta que la verificación pasa.

Esa es toda la idea, y vale la pena ser preciso al respecto porque el nombre lo sobreestima. Una puerta de contraseña es una fricción de acceso delante de un enlace. No es un cifrado de la página detrás del enlace. Esas son garantías diferentes, y confundirlas es como la gente acaba sorprendiéndose después. Esta publicación cubre para qué sirve la puerta, los casos de uso que realmente encajan, cómo funciona la verificación en la redirección, dónde termina la seguridad y con qué combinarla para que todo aguante.

Para qué sirve un enlace corto protegido con contraseña#

Los casos útiles comparten una forma: estás compartiendo un enlace a través de un canal que no controlas completamente, y quieres que se requiera una segunda cosa además de la URL para la entrada.

Un documento sensible es el caso obvio. Estás enviando un borrador de contrato, un modelo financiero o una presentación interna a alguien fuera de tu empresa. Los correos electrónicos se reenvían. Los PDFs se vuelven a enviar. Un enlace corto que cualquier persona con la URL puede abrir es tan privado como la persona menos cuidadosa que alguna vez lo haya tenido. Ponle una contraseña y un reenvío accidental ya no significa acceso automático.

Los entregables de clientes siguen el mismo patrón con una fecha límite adjunta. Una agencia entrega un lote de activos, una edición de video, un informe de campaña. El cliente debería poder acceder, la agenda de contactos completa del cliente no. Una URL restringida mantiene el entregable detrás de un secreto compartido que estableces cuando creas el enlace.

Las campañas privadas y el contenido cerrado completan la lista. Una página de aterrizaje de prelanzamiento que quieres que un pequeño grupo previsualice. Una oferta de acceso anticipado para una lista de espera. Un recurso solo para miembros donde el público ya tiene una contraseña de otro lugar. En cada caso el enlace viaja por correo electrónico o chat, y la contraseña es lo que separa "me dieron esto" de "me topé con esto".

Lo que no encaja: cualquier cosa verdaderamente secreta, cualquier cosa regulada, cualquier cosa donde una filtración sea un incidente reportable. Para esas cosas, una contraseña de enlace compartida es demasiado tosca. Quieres autenticación por persona en el destino en sí, que es un control diferente al que volveré.

Cómo funciona una puerta de contraseña en la redirección#

Aquí está la parte mecánica, porque el orden de las operaciones es lo que hace que la puerta sea significativa.

Un enlace corto normal es una redirección. El borde busca el slug, encuentra el destino y escribe un 302 al navegador del visitante. Rápido, sin estado, sin preguntas. Un enlace corto protegido con contraseña inserta un paso antes de la redirección: el borde ve que el enlace tiene una contraseña establecida, así que en lugar de redirigir, devuelve un desafío. El visitante obtiene una página intermedia que pide la contraseña. La envía. El valor enviado se verifica contra el hash almacenado. Si coincide, la redirección continúa. Si no, permanece en la solicitud y la URL de destino nunca se envía a su navegador.

Diagrama de flujo: un visitante hace clic en un enlace corto, llega a una puerta de contraseña, una contraseña correcta redirige al destino mientras una contraseña incorrecta queda bloqueada

Dos detalles importan para que esto valga algo.

Primero, la contraseña tiene hash, nunca se almacena en texto plano. El secreto almacenado de un enlace debería ser un hash unidireccional para que una lectura de la base de datos no entregue a un atacante todas las contraseñas de los enlaces del sistema. Argon2id es la recomendación actual para el hash de contraseñas, y es lo que Elido usa para las contraseñas de enlaces, con la verificación realizada en proceso usando una comparación de tiempo constante para que la propia verificación no filtre información a través del tiempo. La API de un enlace nunca devuelve el hash; devuelve un booleano que dice si hay una contraseña establecida. Un destinatario que llega a un enlace protegido obtiene un 401 con una bandera password_required y un token de desafío, y tiene que enviar la contraseña correcta en una solicitud de seguimiento antes de que ocurra la redirección. La mecánica de ese almacenamiento está detallada en la lista de verificación de seguridad de acortadores de URL, sección sobre protección por contraseña por enlace.

Segundo, la verificación ocurre antes de revelar el destino. Eso parece obvio, pero un número sorprendente de esquemas de enlaces "privados" filtran el destino en el código del lado del cliente o en una cadena de redirección que un visitante determinado puede leer desde la red. El punto de hacer la verificación en la redirección, del lado del servidor, es que la URL de destino permanece en el servidor hasta que la contraseña sea correcta. Si alguna vez has visto una puerta implementada como JavaScript que obtiene la URL real y luego redirige, has visto una puerta por la que cualquiera con las herramientas de desarrollo del navegador puede pasar directamente. La evaluación del lado del servidor es la diferencia, el mismo razonamiento que hace que los smart links enruten en el borde en lugar de en un shim JS en una página de aterrizaje.

Los límites de seguridad, dichos claramente#

Esta es la sección que la gente se salta y luego lamenta, así que va en el medio donde es difícil pasarla por alto.

Una puerta de contraseña protege el enlace corto. No protege el destino. Si el destino es una URL pública que cualquiera puede alcanzar escribiéndola directamente, entonces la contraseña solo está deteniendo a las personas que tienen el enlace corto, no a las personas que pueden adivinar o toparse con la página subyacente. La puerta eleva el listón para el caso habitual de compartir, donde todo lo que alguien tiene es la URL corta. No hace nada para un destino que ya está expuesto.

Así que la regla es simple: el destino también debería tener control de acceso. Un documento detrás de un enlace corto protegido con contraseña también debería vivir en algún lugar que verifique quién eres, no solo en algún lugar que resulta tener una ruta larga imposible de adivinar. La Hoja de Trucos de Autenticación de OWASP y la guía de Control de Acceso complementaria son la referencia aquí: la autenticación prueba quién es alguien, el control de acceso decide a qué puede llegar, y una contraseña de enlace compartida es una forma débil de lo primero que no dice nada de lo segundo. Úsala como una capa de conveniencia, no como lo que se interpone entre un atacante y datos regulados.

Algunos límites más honestos.

Una contraseña compartida es compartida. Todos los que la tienen son la misma identidad para la puerta. No hay rastro por persona de quién abrió el enlace, no hay forma de revocar el acceso de una persona sin rotar la contraseña para todos. Si necesitas saber que Dana específicamente abrió el entregable, una contraseña de enlace compartida no te lo dirá.

El enlace debería servirse a través de HTTPS, siempre. Una contraseña enviada sobre HTTP plano es una contraseña enviada en claro a cualquiera en la ruta de la red. El cifrado de transporte es el mínimo, no una característica; la descripción general de HTTPS de MDN explica por qué. Elido sirve las redirecciones a través de HTTPS por defecto, incluyendo en dominios personalizados, pero el principio se aplica donde sea que pongas una puerta.

Y una contraseña no es un sustituto de la caducidad. Un enlace que permanece activo para siempre es una responsabilidad independientemente de si tiene contraseña, porque el secreto se filtra lentamente con el tiempo a medida que se pega en más lugares. Combina la puerta con un tiempo de vida.

Con qué combinarlo#

Una puerta de contraseña es un control. Funciona mejor apilada con otros que cubren lo que no puede.

Diagrama de capas apiladas que muestra la puerta de contraseña, la caducidad del enlace, el transporte HTTPS y el control de acceso al destino como controles complementarios, con una nota de que la contraseña sola es fricción, no cifrado

La caducidad y los límites máximos de clics limitan el enlace en tiempo y uso. Establece un expires_at para que un entregable de cliente quede oscuro después de que termine el compromiso, y un límite máximo de clics para que un enlace de descarga de uso único se desactive después de haberse abierto una vez. Ambos se aplican en la redirección antes de que se registre cualquier evento de clic, lo que significa que un intento de contraseña incorrecta contra un enlace ya caducado ni siquiera llega a la puerta. Las compensaciones sobre el tiempo de vida se tratan en la publicación caducidad de enlaces y enlaces autodestructivos.

Los límites de IP o geográficos reducen quién puede intentar acceder a la puerta en absoluto. Si un entregable de cliente solo se abre desde una oficina, restringir el enlace a ese rango significa que una contraseña filtrada más un enlace filtrado aún falla desde cualquier otro lugar. Los controles a nivel regional se tratan en el artículo de geo-targeting para enlaces cortos, y se complementan con la contraseña en lugar de reemplazarla.

Para los equipos, la respuesta correcta normalmente no es una contraseña compartida en absoluto. Es SSO. Cuando las personas que deberían acceder a un enlace son empleados en tu proveedor de identidad, restringe el destino detrás de SCIM y SSO para que el acceso siga el directorio: alguien deja la empresa, su acceso desaparece, no se requiere rotación de contraseña. Una contraseña de enlace compartida es para compartir externo ad-hoc; el acceso gestionado por directorio es para cualquier cosa donde necesites revocación por persona. La guía de configuración de SCIM y SSO explica cómo configurarlo, y la página de soluciones empresariales cubre dónde encaja.

El principio general es la defensa en capas. Ningún control único aquí es fuerte por sí solo. Una contraseña detiene el acceso casual, la caducidad limita la ventana, HTTPS protege la red, el control de acceso al destino protege el contenido y SSO maneja el caso del equipo. Apila los que tu situación necesita.

Una guía práctica#

Si quieres restringir un enlace, la forma del trabajo es la misma independientemente de la herramienta.

Establece la contraseña cuando creas o editas el enlace. Los ajustes del enlace deberían permitirte adjuntar una contraseña; una vez establecida, el enlace deja de ser una redirección simple y empieza a devolver el desafío. Elige una contraseña que no sea trivialmente adivinable y que no se reutilice de otro lugar, porque un secreto compartido que también desbloquea tu correo electrónico es un mal secreto compartido.

Comparte el enlace y la contraseña por canales separados. Este es el hábito de mayor valor. Envía el enlace corto en el correo electrónico o el documento, y envía la contraseña por un mensaje de chat, un correo electrónico separado o una llamada rápida. Si ambos viajan en el mismo mensaje, un solo mensaje interceptado entrega todo y la puerta no te sirvió de nada. Dividirlos significa que un atacante necesita dos canales, no uno.

Establece una caducidad al mismo tiempo. Decide de antemano cuánto tiempo debería vivir el enlace y si debería limitarse después de un número conocido de aperturas, y establécelo cuando lo crees en lugar de prometerte a ti mismo que lo limpiarás después. No lo harás.

Verifica que el destino tiene su propio control de acceso si el contenido es sensible. La puerta está haciendo su trabajo para el caso de compartir. Si el documento subyacente también necesita resistir a alguien que adivine la URL, esa protección tiene que vivir en el destino, no en el enlace corto. Para un tratamiento más completo de cómo estas piezas encajan en un modelo de amenazas, son seguros los acortadores de URL presenta el panorama más amplio, y la página de confianza cubre la postura de Elido.

Esta es la versión honesta de los enlaces cortos protegidos con contraseña. Son una forma útil y de baja fricción de evitar que una URL compartida esté abierta a cualquiera que la reciba. No son una caja fuerte. Usados como una capa en una pila, con caducidad y un destino correctamente controlado por acceso, hacen exactamente el trabajo que deben hacer. Usados como la única cosa entre un atacante y algo que importa, te fallarán. Establece la puerta, divide los canales, limita el tiempo de vida y bloquea el destino, y tendrás un flujo de compartición que aguanta.

Si quieres ver qué controles llegan a qué plan, la página de precios los lista, y la función de dominios personalizados cubre cómo servir enlaces restringidos en tu propio dominio de marca a través de HTTPS. La configuración se explica en cómo configurar enlaces cortos de marca.

Relacionado en el blog#

Prueba Elido

Acortador de URL alojado en la UE: dominios personalizados, análisis profundo y API abierta. Plan gratuito - sin tarjeta de crédito.

Etiquetas
password protected short links
private short link
secure link sharing
gated url
password protected url
share a link securely

Seguir leyendo