Entrevista de backend: ¿Cómo actualizarías el inicio de sesión por cookies a sesiones vinculadas al dispositivo?

Planteamiento y contexto

Un sistema de inicio de sesión existente mantiene a los usuarios autenticados mediante cookies de larga duración. El equipo de seguridad desea reducir la reproducción entre dispositivos tras el robo de cookies, pero no puede actualizar a todos los clientes a la vez ni provocar cierres de sesión masivos durante la rotación de claves, el reinicio del navegador o la recuperación de dispositivos. Diseña una integración de DBSC que contemple el registro, la renovación, la revocación, el mecanismo de fallback, la auditoría y el despliegue gradual.

Qué evalúa el entrevistador

• Si separas la sesión de identidad de larga duración, la cookie de autorización de corta duración y la clave privada del dispositivo.
• Si puedes explicar los endpoints de registro y renovación, el desafío-respuesta (challenge-response) y los registros de vinculación en el servidor.
• Si gestionas claves no exportables, navegadores no compatibles, cookies faltantes y migración de dispositivos.
• Si diseñas la revocación, la rotación de claves, la renovación concurrente y la detección de anomalías.
• Si los límites de compatibilidad y seguridad se reflejan en el despliegue, el monitoreo y la reversión (rollback).

Preguntas para aclarar primero

1. ¿Qué cuentas u operaciones requieren vinculación al dispositivo y cuáles pueden conservar cookies ordinarias?
2. ¿Cuáles son la duración máxima de la sesión, el intervalo de renovación y la tasa aceptable de reautenticación?
3. ¿Se requiere soporte para múltiples dispositivos, proxies empresariales, dispositivos sin TPM o subdominios entre sitios?
4. Tras un fallo de prueba, ¿el sistema debe cerrar la sesión, recurrir a MFA o congelar las acciones de alto riesgo?
5. ¿Puede el gateway existente transmitir los encabezados de registro y renovación, y qué campos está permitido registrar en logs?

Una respuesta de 30 segundos

«Mantendría el estado de inicio de sesión existente como una capa de compatibilidad. Tras iniciar sesión, una respuesta Secure-Session-Registration le solicita al navegador que cree una clave de dispositivo. El servidor almacena únicamente la clave pública, el identificador de sesión, el endpoint de renovación, el alcance (scope) y el estado, reemplazando luego la cookie de larga duración por una de corta duración. Cuando esta expira, el navegador llama al endpoint de renovación con una prueba de clave; el servidor verifica la firma, el desafío, la sesión y la política de riesgo antes de emitir una nueva cookie. Los fallos de registro o renovación recurren a una sesión ordinaria o a MFA según las capacidades y el riesgo. La revocación, la rotación, la auditoría y las métricas de despliegue controlan la expansión».

Análisis detallado paso a paso

1. Definir los límites de confianza y el estado

El servicio de inicio de sesión sigue autenticando al usuario; la capa DBSC demuestra que el navegador posee la clave privada vinculada a la sesión. Almacena sessionId, la clave pública, la versión de la clave, la URL de renovación, el alcance, el nombre de la cookie de corta duración, el estado y la hora de la última prueba. Nunca almacenes la clave privada ni trates a la clave pública por sí misma como la identidad del usuario.

2. Registrar una sesión vinculada al dispositivo

Tras un inicio de sesión exitoso, devuelve el encabezado de respuesta de registro. El navegador genera un par de claves y envía la clave pública al endpoint de registro. El servidor valida un token de registro de un solo uso, la sesión de inicio de sesión y el origen, escribe la vinculación y devuelve instrucciones de sesión en JSON junto con una cookie de corta duración. El registro debe ser idempotente para que los reintentos no creen una vinculación huérfana irretirable.

Secure-Session-Registration: (ES256); path="/StartSession"
Set-Cookie: auth_cookie=short-lived; Max-Age=600; Secure; HttpOnly; SameSite=Lax

3. Verificar la prueba de clave durante la renovación

Cuando la cookie de corta duración está próxima a expirar, el navegador llama al endpoint de renovación con un JWT de prueba DBSC. Valida el algoritmo de firma, el desafío, el identificador de sesión, la ventana de tiempo, la versión de la clave y el alcance; luego, avanza atómicamente el desafío o el contador de renovación. No extiendas silenciosamente una cookie antigua tras una prueba fallida; devuelve un motivo observable y aplica la política de riesgo.

4. Gestionar el fallback y múltiples dispositivos

DBSC es aditivo. Mantén una sesión ordinaria cuando el navegador o el hardware no lo admitan, exigiendo MFA para acciones de alto riesgo. Almacena una vinculación por dispositivo; revocar un dispositivo solo elimina esa vinculación, mientras que un cierre de sesión global revoca todas las vinculaciones y sesiones ordinarias. La ruta de fallback requiere una duración más corta y límites de tasa (rate limits) para evitar que se convierta en una vía de elusión.

5. Diseñar la rotación, concurrencia y recuperación

La rotación de claves crea una nueva versión con una breve ventana de superposición; a la versión antigua solo se le permite una migración controlada. Utiliza un bloqueo de sesión o una actualización condicional de versión para que las renovaciones concurrentes no sobrescriban los desafíos entre sí. La restauración del navegador, la limpieza de datos del sitio o la pérdida de una clave revocan la vinculación antigua y requieren una nueva autenticación; un fallo de renovación no debe convertirse automáticamente en un bloqueo permanente.

6. Monitorear, auditar y desplegar gradualmente

Registra el éxito del registro, los fallos de prueba, la latencia de renovación, la tasa de fallback, el motivo de revocación de dispositivos y la distribución de versiones de navegadores, pero nunca claves privadas. Comienza con cuentas de bajo riesgo y compara las alertas de secuestro con los inicios de sesión exitosos. Si los fallos aumentan, retira el encabezado de respuesta de registro para detener nuevas vinculaciones mientras mantienes la ruta de cookies ordinarias. Escribe los cambios de políticas y de versiones de clave en un registro de auditoría inmutable.

Ejemplo de una respuesta sólida

«DBSC solo demuestra que el navegador posee la clave privada vinculada a una sesión; el sistema de inicio de sesión existente continúa autenticando al usuario. Tras iniciar sesión, el servidor utiliza un encabezado de respuesta de registro para que el navegador cree una clave y envíe su parte pública, sustituyendo luego la cookie de larga duración por una de corta duración. El endpoint de renovación valida la firma del JWT de prueba, el desafío, la sesión, el tiempo y el alcance antes de avanzar atómicamente el desafío y emitir una nueva cookie. El servidor almacena la clave pública, el estado, la versión y los datos de auditoría, nunca la clave privada. Múltiples dispositivos obtienen vinculaciones independientes, y la revocación puede dirigirse a un solo dispositivo o a todo el usuario. Los clientes no compatibles utilizan una sesión ordinaria restringida o MFA. Durante el despliegue, se monitorean los fallos de prueba, el fallback y los inicios de sesión exitosos; si el riesgo se incrementa, se retira el encabezado de registro y se mantiene la compatibilidad».

Errores comunes

• Tratar la clave pública como la identidad del usuario → se mezclan los conceptos de vinculación y autenticación → úsala únicamente como material de prueba de sesión.
• Limitarse a acortar la duración de la cookie de larga duración → un atacante aún puede reproducirla durante su tiempo de vida → vincula la cookie de corta duración a la prueba de clave.
• Omitir la protección contra reproducción en la renovación → una misma prueba puede ser reutilizada → vincula un desafío de un solo uso, una ventana de tiempo y una actualización atómica de estado.
• Cerrar la sesión de todos los usuarios sin soporte → la compatibilidad y la disponibilidad se ven afectadas → recurre a una sesión ordinaria o a MFA según la capacidad y el riesgo.
• Tratar a DBSC como irrevocable → un dispositivo extraviado no se puede aislar → proporciona revocación a nivel de dispositivo y de usuario con auditoría.

Preguntas de seguimiento y respuestas

¿Una clave privada detiene todas las formas de robo de cookies?

No. DBSC reduce principalmente la reproducción directa después de que una cookie se exporta a otro dispositivo. El malware que controla el dispositivo original, los ataques durante el inicio de sesión o un servidor comprometido siguen requiriendo otras defensas. Especifica explícitamente el modelo de amenazas y el riesgo residual.

¿Por qué mantener una ruta de sesión ordinaria?

Las capacidades de los navegadores, el hardware y las redes corporativas varían, y DBSC sigue evolucionando como estándar. Una ruta de compatibilidad restringida evita cierres de sesión masivos; las acciones de alto riesgo pueden exigir verificaciones más estrictas en lugar de hacer que el inicio de sesión falle.

¿Cómo se evitan las condiciones de carrera en renovaciones concurrentes?

Utiliza actualizaciones condicionales sobre sessionId y la versión de la clave, acepta únicamente el desafío actual y escribe de forma atómica el siguiente desafío y la versión de la cookie. Las solicitudes duplicadas pueden recibir el mismo resultado o ser solicitadas a renovar nuevamente, evitando que las respuestas se sobrescriban entre sí.

¿Qué sucede durante la migración o restauración de un dispositivo?

Regístralo como un dispositivo nuevo en lugar de copiar la clave privada anterior. Mantén la vinculación antigua durante un breve período de gracia con verificaciones de riesgo; tras la reautenticación, crea una nueva vinculación de clave pública y permite que el usuario revoque el registro anterior desde la administración de dispositivos.