Compartir trabajo del navegador sin compartir credenciales sin procesar

Los equipos suelen decir que necesitan «compartir un inicio de sesión» cuando la necesidad real es más acotada: revisar un borrador, actualizar una tienda autorizada, reproducir un defecto regional o continuar un flujo de asistencia. Partir de la tarea ofrece más opciones que partir de la contraseña.

Qué se considera una credencial sin procesar

Los ejemplos evidentes son las contraseñas, los códigos de recuperación, las semillas de contraseñas de un solo uso, las claves privadas y las contraseñas de proxy. El trabajo en el navegador también introduce credenciales menos visibles:

• cookies de autenticación e identificadores de sesión;
• tokens de acceso y renovación de OAuth;
• registros del gestor de contraseñas y datos de Autorrelleno;
• material de clave privada de llaves de acceso o acceso al autenticador que lo conserva;
• estado de dispositivo de confianza y recuperación; y
• un archivo de perfil que contenga cualquiera de los elementos anteriores.

Las indicaciones de NIST sobre sesiones describen una sesión del navegador como la continuidad basada en la posesión de un secreto de sesión. La OWASP Session Management Cheat Sheet deja clara la consecuencia operativa: mientras sea válido, un token de sesión puede equivaler a la autenticación más fuerte que lo creó.

Un paquete cifrado del perfil no expone esos valores al proveedor de almacenamiento ni a un observador casual. Después de que el dispositivo de un destinatario autorizado lo descifre e inicie el perfil, el navegador puede seguir ejerciendo la sesión. El traspaso ha transferido autoridad aunque el destinatario nunca lea una cookie.

Separa la tarea de la autoridad

Antes de elegir un mecanismo para compartir, escribe una breve declaración de acceso:

El operador nominal A puede realizar las acciones B sobre el recurso C, desde el dispositivo aprobado D, hasta el momento E, con la regla de aprobación y auditoría F.

Esta frase deja al descubierto la autoridad innecesaria. Si la tarea consiste en «aprobar este borrador», una sesión administrativa completa es excesiva. Si el servicio ya ofrece un rol de revisor, compartir el estado del navegador añade riesgo sin aportar capacidad.

La Zero Trust Architecture de NIST recomienda el acceso a cada recurso por sesión con los privilegios mínimos necesarios para la tarea. Este principio se aplica sin necesidad de adoptar un producto con la etiqueta «confianza cero». Es una prueba de diseño útil para cualquier traspaso en el navegador.

Prefiere estos modelos en este orden

1. Acceso nominal en el servicio de destino

Utiliza la función de equipos, organizaciones, roles, delegación o aprobación del sitio o propietario de la aplicación cuando exista. Cada persona se autentica con una cuenta y un autenticador individuales. El servicio de destino puede aplicar entonces sus permisos, atribuir acciones al operador, utilizar sus controles de riesgo y revocar a una persona sin cambiar las credenciales de todos.

Suele ser el modelo más fuerte porque la autorización reside donde se entiende la acción. Un gestor del navegador no puede convertir de forma fiable la sesión compartida de administrador de un sitio en un rol de revisor dentro de ese sitio.

Las cuentas compartidas y de grupo reducen la responsabilidad. NIST SP 800-53 Rev. 5 aconseja a las organizaciones restringir su uso y definir condiciones explícitas antes de permitirlas.

2. Delegación limitada desde el servicio de destino

Cuando un servicio ofrece OAuth u otro protocolo de delegación, concede a un cliente o actor únicamente los recursos, las acciones y la duración necesarios. RFC 9700 recomienda limitar al mínimo los privilegios de los tokens de acceso y restringir su destinatario al servidor de recursos previsto.

Prefiere concesiones de corta duración, revocables y restringidas a un destinatario. Los tokens vinculados al remitente pueden reducir la reutilización si se filtra un token, pero no ayudan cuando un atacante obtiene tanto el token como el material de clave al que está vinculado. El dispositivo cliente y su software permanecen dentro del límite de la amenaza.

La delegación resulta especialmente útil para la automatización porque un script puede recibir permiso para una operación definida sin obtener la contraseña o la sesión general del navegador de una persona. El evento de auditoría debe identificar a la persona que inicia la acción, el actor delegado, el recurso, el alcance y el resultado.

3. Uso intermediado de un secreto almacenado

Algunos servicios antiguos solo exponen una credencial compartida. Un intermediario controlado de credenciales o un gestor de contraseñas puede reducir las copias al permitir que un flujo aprobado del navegador use un secreto sin mostrarlo en chats, incidencias, documentos ni salidas normales de la aplicación.

Esto mejora la custodia, la rotación y la revisión del acceso, pero no repara el modelo de cuentas del servicio de destino. Después de iniciar sesión, todos los operadores pueden seguir actuando como la misma identidad del sitio. La sesión resultante continúa siendo sensible y necesita sus propios controles de tiempo de espera, revocación y dispositivo.

La OWASP Secrets Management Cheat Sheet recomienda acceso granular, interacción humana mínima con los valores secretos, controles del ciclo de vida y auditoría de quién solicitó y utilizó un secreto. Cuando sea posible, un producto de navegador debe integrarse mediante una referencia opaca, en lugar de convertirse en otro almacén de secretos de uso general.

4. Traspaso protegido de una sesión del navegador

Utiliza un perfil autenticado compartido solo cuando el servicio de destino carezca de una delegación adecuada y el flujo autorizado necesite realmente la continuidad de la sesión. Es el traspaso normal de mayor riesgo porque el destinatario recibe la capacidad de actuar mediante la cuenta activa.

Los controles mínimos incluyen:

• un propietario y un destinatario aprobado explícitos;
• una tarea, un recurso y una hora de caducidad declarados;
• un escritor activo o un modelo de conflictos probado;
• cifrado en el cliente antes de cualquier subida a la nube;
• autorización del dispositivo del destinatario y protección local;
• un bloqueo que impida trabajo simultáneo ambiguo;
• eventos de auditoría para la concesión, la descarga, la apertura, la acción sensible, el cierre, la revocación y la recuperación;
• interfaces normales que devuelvan estado oculto en lugar de cookies o tokens; y
• un plan para revocar la sesión en el servicio de destino.

Este modelo puede proteger el valor de la credencial frente a copias casuales y al almacenamiento en la nube. No puede hacer que el servicio de destino distinga entre dos personas que usan la misma cuenta autenticada. Tampoco puede proteger la sesión frente a malware, una extensión maliciosa o un destinatario autorizado que abuse de la autoridad concedida.

5. Transferencia de credenciales sin procesar

Copiar una contraseña, cookie, código de recuperación, llave de acceso o archivo de perfil en un mensaje, una hoja de cálculo, una incidencia, un script o una exportación sin proteger crea un secreto duradero con copias inciertas y revocación débil. Evítalo.

Si un proceso antiguo excepcional exige transferirlo, sigue el procedimiento de credenciales aprobado por la organización, reduce al mínimo los destinatarios y la duración, y rota o revoca después la credencial. No trates el cifrado del mensaje como sustituto de la responsabilidad individual ni como registro de cada copia.

Compara la autoridad, no solo la comodidad

Modelo	El servicio de destino identifica al operador	El alcance puede ajustarse a la tarea	Límite de revocación	Riesgo residual principal
Miembro nominal del servicio de destino	Normalmente sí	Suele ser el más fuerte	Eliminar a un miembro o rol	Permisos excesivos en el servicio de destino
Token delegado y limitado	Pueden representarse el actor y el cliente	Fuerte cuando el alcance y el destinatario son reducidos	Revocar la concesión o el token	Vulneración del token, el cliente o la clave
Inicio de sesión compartido e intermediado	A menudo no, después de iniciar sesión	Limitado por la cuenta compartida	Rotar el secreto y terminar las sesiones	Identidad compartida en el sitio y sesiones activas
Sesión cifrada del navegador	Normalmente no en el servicio de destino	A nivel del perfil y, a menudo, amplio	Revocar el uso compartido y la sesión de destino	El dispositivo del destinatario puede ejercer toda la autoridad de la sesión
Copia de la credencial sin procesar	Sin identidad individual fiable	Normalmente amplio	Encontrar las copias, rotar y terminar las sesiones	Copias desconocidas y responsabilidad débil

La tabla explica por qué «nadie puede ver la contraseña» es un criterio de éxito incompleto. El resultado importante es cuánta autoridad puede ejercer el destinatario, durante cuánto tiempo y qué sistema puede revocarla.

Las llaves de acceso mejoran la autenticación, con una salvedad al compartirlas

WebAuthn crea una credencial de clave pública limitada a una parte autenticadora. La especificación WebAuthn Level 3 señala que el autenticador conserva la clave privada y el script del sitio recibe resultados firmados, no la credencial privada. Esto ofrece autenticación resistente al phishing cuando se implementa correctamente.

Las llaves de acceso no crean automáticamente roles de equipo. Un servicio de destino puede registrar una credencial distinta para cada miembro nominal y conservar así el acceso individual. Un proveedor de llaves de acceso también puede admitir la sincronización o el uso compartido de claves de autenticación. NIST SP 800-63B-4 reconoce ese modelo e identifica riesgos como el uso no autorizado de claves, su proliferación entre dispositivos, la vulneración de la infraestructura de sincronización y una revocación difícil.

Para un equipo autorizado, prefiere una cuenta nominal del servicio y un autenticador por persona. Si una llave de acceso compartida es el único modelo disponible, trátala como un autenticador compartido, documenta quién puede recibirla y en qué dispositivos administrados, y verifica cómo muestra, revoca y recupera el proveedor las claves compartidas. El servicio de destino puede seguir registrando todas las acciones en una sola cuenta.

Define el traspaso del navegador como un contrato

Un traspaso controlado debe responder estas preguntas antes de mover el estado del perfil:

1. ¿Quién actúa? Utiliza una identidad nominal de la organización, nunca una etiqueta genérica de operador.
2. ¿Quién lo autorizó? Registra al propietario o la decisión de la política sin guardar secretos de aprobación.
3. ¿Qué se comparte? Identifica el perfil y la tarea. Evita un inventario sin procesar de sus cookies o credenciales.
4. ¿Qué puede hacer el destinatario? Separa permisos de inicio, edición, exportación, automatización, uso compartido y administración.
5. ¿Dónde puede ejecutarse? Limita el acceso a dispositivos registrados y de confianza adecuados para los datos.
6. ¿Cuánto dura? Establece una caducidad y cierra las sesiones inactivas.
7. ¿Pueden actuar dos escritores? Utiliza uno activo salvo que el comportamiento ante conflictos se haya diseñado y probado expresamente.
8. ¿Qué se registra? Registra actor, dispositivo, referencia del perfil, acción, resultado y hora. Excluye de forma predeterminada valores secretos y contenido de las páginas.
9. ¿Cómo se revoca? Incluye tanto la concesión para compartir el navegador como la sesión del servicio de destino.
10. ¿Cómo se recupera? Conserva una última versión correcta conocida sin restaurar por accidente una autoridad revocada.

El cifrado forma parte de este contrato. Protege los datos mientras se almacenan o transfieren. La autorización decide quién puede obtener la vía de descifrado. La confianza del dispositivo y el aislamiento local protegen el uso. La auditoría respalda la responsabilidad y la investigación. Ninguno de estos controles sustituye a los demás.

Mantén la automatización fuera del límite de los secretos

Las API, los SDK, las herramientas de línea de comandos y los agentes suelen necesitar iniciar un perfil o ejecutar una acción aprobada de su ciclo de vida. Rara vez necesitan valores de cookies, contraseñas, llaves de acceso, credenciales de proxy o un archivo de perfil sin procesar.

Una interfaz acotada puede aceptar una referencia opaca al perfil o al secreto y devolver:

• si la acción se autorizó;
• un estado oculto como preparado, bloqueado, caducado o revocado;
• una referencia de proceso o sesión con duración limitada;
• un error estructurado y un paso de recuperación; y
• una referencia al evento de auditoría.

No debe devolver una credencial por el mero hecho de que quien llama pueda iniciar el perfil. La exportación, el uso compartido masivo u otra operación portadora de secretos requiere una política independiente y, cuando corresponda, aprobación explícita.

El contenido de los sitios web y las entradas de automatización también siguen sin ser fiables. Una instrucción de una página no debe poder persuadir a un agente para que revele material de sesión mediante registros, salidas de herramientas, capturas de pantalla o un canal de asistencia.

La revocación tiene dos capas

Eliminar a un colaborador de un espacio de trabajo del navegador detiene el acceso autorizado futuro mediante ese espacio. No demuestra que la sesión del servicio de destino sea inválida. Un dispositivo puede conservar ya un estado descifrado, y una sesión copiada o aún en ejecución puede continuar.

Cuando el acceso finaliza de forma normal:

1. revoca la concesión del equipo y cierra el arrendamiento del perfil;
2. elimina el material local cifrado conforme a la política de conservación;
3. termina la sesión correspondiente en el servicio de destino cuando sea posible;
4. elimina la pertenencia de la persona al servicio de destino o su concesión delegada; y
5. conserva pruebas de auditoría ocultas durante el periodo aprobado.

Cuando se sospeche una vulneración, pon también en cuarentena las versiones afectadas del perfil, revoca las sesiones y tokens activos, elimina autenticadores no autorizados, rota los secretos compartidos expuestos y revisa los eventos de auditoría. Restaurar una instantánea antigua del perfil puede restaurar un secreto de sesión anterior, por lo que la recuperación debe respetar el estado de revocación.

Límites que permanecen tras un traspaso cuidadoso

• El cifrado en el cliente protege los datos almacenados y transmitidos, pero un endpoint autorizado debe descifrar lo que necesita el navegador.
• Un bloqueo del navegador controla la concurrencia dentro del producto, no todas las acciones del servicio de destino.
• Una sesión compartida suele presentar una sola identidad de cuenta al servicio de destino, con independencia de que el producto del navegador mantenga una auditoría más rica.
• Un dispositivo o una extensión vulnerados pueden actuar mediante una sesión válida sin extraer una contraseña legible.
• Revocar una concesión del espacio de trabajo y revocar una sesión de un sitio son operaciones independientes.
• Las condiciones del servicio de destino, el contrato del cliente y la legislación aplicable siguen determinando si un flujo puede delegarse.
• Algunos servicios no ofrecen ningún sustituto seguro para el acceso individual. En ese caso, reducir el alcance o rechazar el traspaso puede ser la decisión responsable.

RFC 6265 describe las cookies como autoridad ambiental: un navegador puede adjuntarlas a una solicitud aunque la parte que la provoca nunca conozca el valor de la cookie. Esta es la limitación central de compartir sesiones. Ocultar las credenciales reduce su divulgación, pero no la autoridad que el navegador puede ejercer.