Enunciado y contexto adecuado
El SaaS ya admite contraseñas y está agregando passkeys. Un usuario puede iniciar sesión desde un teléfono, una laptop o una llave de seguridad por hardware; algunas credenciales pueden sincronizarse mediante una plataforma, mientras que las acciones empresariales de alto riesgo requieren una verificación de usuario más sólida. Diseña el registro, la autenticación, la recuperación, la migración y la observabilidad.
El alcance es WebAuthn y el límite de verificación del servidor. Las passkeys no resuelven automáticamente la gestión de sesiones, la recuperación de cuentas, la revocación de dispositivos ni la autorización empresarial.
Qué evalúa el entrevistador
El entrevistador verifica si comprendes que el navegador y el autenticador guardan la clave privada mientras el servidor almacena la clave pública; que cada ceremonia usa un desafío aleatorio de un solo uso; y que el verificador comprueba el desafío, el RP ID, el origen, la firma y las flags requeridas de presencia de usuario o verificación de usuario.
Una respuesta sólida también separa "resistente al phishing" de "nunca se pierde". Las credenciales sincronizables mejoran la disponibilidad, pero pueden no cumplir con los requisitos más estrictos de no exportabilidad. Si la recuperación elude una prueba equivalente, todo el diseño es tan fuerte como su ruta más débil.
Aclaraciones para hacer primero
- ¿Qué acciones requieren solo inicio de sesión y cuáles requieren UV o una credencial vinculada al dispositivo?
- ¿El RP ID cubre múltiples subdominios y se ejecutará WebAuthn en un iframe de origen cruzado?
- ¿Puede la empresa prohibir las credenciales sincronizables o requerir llaves de hardware?
- ¿Qué factores existentes se mantienen para la recuperación y puede revisarla un operador?
- ¿Cuál es el cronograma de migración y revocación para contraseñas, TOTP y passkeys?
Marco de respuesta de 30 segundos
"El servidor crea un desafío de un solo uso para cada registro o autenticación y lo vincula a una sesión. Tras la ceremonia, verifica el RP ID, el origen, el desafío, la firma y las flags UP/UV requeridas. El registro almacena la clave pública, el ID de la credencial, el contador y los metadatos de política, nunca la clave privada. Yo estratificaría las credenciales sincronizables según el riesgo y requeriría UV o vinculación al dispositivo para acciones sensibles. La recuperación utiliza factores fuertes existentes, un flujo efímero de un solo uso y revisión de riesgos; el SMS no es una puerta trasera incondicional".
Respuesta detallada paso a paso
Paso 1: Definir los datos de registro y autenticación
Antes del registro, el servidor crea un desafío impredecible, efímero y de un solo uso, y lo almacena en una sesión o almacén de un solo uso. El cliente llama a navigator.credentials.create(); el autenticador crea un par de claves y devuelve una credencial de clave pública.
Almacena el ID de la credencial, la clave pública, la cuenta, el RP ID, el contador de firmas, la elegibilidad de respaldo y el estado de respaldo según sea necesario. La clave privada permanece en el autenticador o en el administrador de credenciales de la plataforma.
Paso 2: Realizar comprobaciones estrictas de autenticación
Para el inicio de sesión, el servidor crea un desafío nuevo y publicKeyCredentialRequestOptions; el cliente llama a navigator.credentials.get(). Verifica:
const valid = await verifyAuthenticationResponse({
response,
expectedChallenge: session.challenge,
expectedOrigin: "https://app.example.com",
expectedRPID: "app.example.com",
requireUserVerification: true
});Consume el desafío inmediatamente después de una verificación exitosa. Rechaza respuestas reproducidas, expiradas o de sesiones cruzadas, y luego verifica la firma con la clave pública almacenada. Maneja también cancelaciones, navegadores no compatibles y autenticadores temporalmente no disponibles.
Paso 3: Comprender los RP IDs, los orígenes y el riesgo de origen cruzado
El RP ID identifica a la parte usuaria (relying party) para una credencial; una credencial no puede autenticarse ante un RP ID diferente. El servidor también debe comprobar el origen que realiza la llamada en lugar de comparar solo un dominio registrable. Un iframe de origen cruzado o un Related Origin Request requiere una revisión explícita de si el usuario sabe quién está solicitando la ceremonia y una prueba de compatibilidad independiente.
El logotipo de una empresa no es prueba del origen. El origen, el RP ID, el desafío y la firma deben verificarse juntos en todo el contexto del navegador/autenticador y el servidor.
Paso 4: Razonar sobre UP, UV y el estado de sincronización según el riesgo
UP significa que el usuario interactuó con el autenticador; UV significa que el autenticador verificó localmente al usuario. El inicio de sesión ordinario puede elegir una política según el riesgo, mientras que las transferencias, la exportación de claves y las acciones de administrador deben requerir UV y hacer que el servidor inspeccione la flag devuelta.
Las credenciales sincronizables mejoran la disponibilidad entre dispositivos, pero el NIST señala que la sincronización implica la exportabilidad de claves. Que eso cumpla con un nivel de aseguramiento depende de la política de despliegue. Registra la elegibilidad y el estado del respaldo; no llames a lo "sincronizable" "ya sincronizado" ni "vinculado al dispositivo".
Paso 5: Diseñar la recuperación, migración y revocación
Cuando un usuario pierde un dispositivo, da prioridad a otra passkey registrada, una clave de recuperación empresarial o un flujo revisado de identidad fuerte. Un token de recuperación debe ser efímero, de un solo uso, vinculado a la sesión y revocable. Tras la recuperación, notifica al usuario, rota las sesiones y permite que el usuario revise y elimine credenciales antiguas.
Durante la migración de contraseñas, mantén un período de transición controlado y reduce la dependencia de las contraseñas después de crear una passkey; no elimines silenciosamente todos los factores antiguos en la misma solicitud. Cada credencial necesita un estado de revocación independiente, mientras que los contadores anómalos, los dispositivos riesgosos y los eventos de recuperación ingresan al flujo de auditoría.
Respuesta de muestra de alta calidad
"Comenzaría estratificando los objetivos de seguridad. El servidor crea un desafío de un solo uso para cada registro y autenticación y lo almacena en una sesión efímera. Verifica el desafío, el RP ID, el origen, la firma y las flags UP/UV requeridas para esa acción, y luego consume el desafío. La base de datos almacena la clave pública, el ID de la credencial, el contador, la cuenta y el estado de respaldo; la clave privada nunca sale del autenticador.
No habilitaría el uso de iframes de origen cruzado por defecto. Si fuera necesario, incluiría el origen del llamador, el origen de nivel superior y el RP ID en la matriz de pruebas. El inicio de sesión ordinario puede aceptar credenciales sincronizables que cumplan con la política, mientras que las acciones sensibles requieren UV o vinculación al dispositivo. La recuperación da prioridad a otra passkey fuerte o a una clave de recuperación empresarial, con vencimiento de un solo uso, controles de riesgo y notificación. El SMS puede ser un fallback aceptado explícitamente, nunca una vía permanente para eludir la autenticación fuerte. La telemetría de producción monitorea la reproducción de desafíos, discrepancias de origen, falta de UV, recuperaciones exitosas y revocaciones anómalas".
Errores comunes
- Verificar solo la firma → una firma válida no prueba el desafío, RP ID u origen correctos → comprueba cada campo y consume el desafío.
- Tratar UP como UV → tocar un autenticador no es verificación local del usuario → requiere e inspecciona UV para acciones de alto riesgo.
- Llamar vinculada al dispositivo a una passkey sincronizable → la elegibilidad de sincronización y la sincronización real son hechos distintos → registra las flags de respaldo y decide según el nivel de aseguramiento.
- Recuperar con un enlace por SMS de inmediato → la ruta más débil puede comprometer la cuenta → usa factores fuertes existentes, tokens efímeros, revisión de riesgos y notificación.
- Comprobar solo el dominio registrable → un origen incluye esquema, host y puerto → compara el origen completo normalizado.
- Reutilizar desafíos → una aserción interceptada puede reproducirse → haz que los desafíos sean aleatorios, efímeros, de un solo uso y vinculados a la sesión.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué las passkeys son resistentes al phishing?
El autenticador selecciona las credenciales basándose en el origen y el RP ID, y firma el desafío del servidor con su contexto. Un sitio de phishing no puede obtener del autenticador una prueba válida para el servicio real. El servidor aún debe verificar el origen, el RP ID y el desafío.
Pregunta de seguimiento 2: ¿Por qué no mantener el desafío únicamente en el cliente?
El servidor debe conocer el valor aleatorio que emitió para vincular la respuesta con la intención de inicio de sesión actual y rechazar reproducciones. Un valor generado por el cliente o almacenado por separado no prueba que el servidor haya iniciado esta ceremonia.
Pregunta de seguimiento 3: ¿Las credenciales sincronizables son intrínsecamente inseguras?
Evita una afirmación binaria. La sincronización mejora la recuperación y la usabilidad multidispositivo, mientras que la exportabilidad, la política del proveedor y los requisitos de aseguramiento organizacional difieren. El servidor debe inspeccionar las flags de respaldo por nivel de riesgo y requerir factores más fuertes para acciones sensibles.
Pregunta de seguimiento 4: ¿Qué pasa si el usuario pierde todos los dispositivos?
Trata la recuperación como una autenticación de alto riesgo: usa una clave de recuperación empresarial, otro factor fuerte revisado o una revisión por parte de un operador, con alcance y tiempo limitados, notificación y revocación de credenciales desconocidas. La conveniencia no debe reducir permanentemente el nivel de aseguramiento del inicio de sesión.