Recuperación de claves de acceso: qué probar antes de exigirlas

Un simulacro de recuperación de claves de acceso comprueba cómo recupera el acceso alguien del equipo cuando su autenticador habitual no está disponible. Antes de exigirlas, ensaya tanto el uso de una credencial de reserva como la pérdida de todas las credenciales utilizables. Comprueba quién puede autorizar el registro de una nueva, qué cuentas siguen siendo accesibles y qué ocurre con las sesiones que ya estaban abiertas.

Es una respuesta práctica al debate de esta semana en Hacker News. En su artículo del 14 de octubre, «Passkeys Are Not a Trap», Scott Helme cuestiona varias afirmaciones sobre la declaración de propiedades de los autenticadores. La conversación también plantea dudas cotidianas: ¿dónde se guardó la credencial?, ¿qué ocurre en otro dispositivo?, ¿quién ayuda si desaparece? Son experiencias personales, no una tasa de fallos medida. Aun así, describen situaciones que tu puesta en marcha debe resolver.

Puedes defender una autenticación resistente al phishing y exigir un proceso de recuperación que se pueda usar. En una startup, la forma de evaluarlo es probarlo antes de que alguien lo necesite en plena entrevista o durante un incidente en producción.

Empieza con un portátil perdido

Usa un espacio de trabajo de prueba y una compañera ficticia, Maya. Tiene una entrevista dentro de media hora, su portátil habitual no está disponible y necesita entrar en el sistema de selección desde otro navegador. El ensayo debe aclarar qué puede hacer realmente, incluidos los pasos que requieren ayuda de otra persona.

Anota su situación inicial antes de cambiar la configuración. ¿Qué credencial utiliza normalmente? ¿Dónde está guardada? ¿Puede usar el móvil sin el portátil? ¿Tiene ya registrada una llave de seguridad independiente? ¿Puede acceder al correo que se usa para la recuperación? ¿Quién tiene permiso para ayudarla?

Cada pregunta señala una dependencia distinta. El móvil puede guardar una clave de acceso sincronizada, recibir el correo de recuperación y autorizar el acceso al gestor de contraseñas. Apuntarlo tres veces no crea tres vías independientes para volver a entrar.

Primero, deja disponible una credencial de reserva ya registrada y considera inaccesible el dispositivo habitual durante el ejercicio. Abre otro navegador y autentícate con la credencial de reserva. Ver una segunda credencial en la configuración de la cuenta no basta: hay que comprobar si Maya puede usarla en las condiciones que tendría tras la pérdida.

Después, intenta registrar una credencial nueva. Aunque una página siga abierta, la aplicación puede pedir que vuelvas a autenticarte antes de permitir cambios. Anota en qué momento lo exige, qué método acepta y si la credencial de reserva permite completar ese paso.

Registra el tiempo y los obstáculos que observes. No necesitas copiar el objetivo de otra empresa. Necesitas pruebas suficientes para decidir si tu equipo puede asumir la interrupción y si las instrucciones se entienden sin tener al lado a quien las diseñó.

Distingue el acceso de reserva de la recuperación de la cuenta

Usar una credencial registrada que todavía está disponible es distinto de pedir a una aplicación que vuelva a verificar quién eres cuando ya no queda ninguna credencial utilizable. Dales nombres distintos en las instrucciones: exigen cosas diferentes al usuario y al administrador.

El documento de la FIDO Alliance sobre implantación en empresas distingue las claves de acceso sincronizadas de las credenciales vinculadas a una llave física. La sincronización puede ayudar al cambiar de dispositivo. Una llave registrada de antemano puede ofrecer otra vía de autenticación. Su utilidad depende de que esté disponible y sea compatible con el entorno en el que la necesite la persona del equipo.

Supón que Maya puede usar una credencial sincronizada desde el móvil cuando falla el portátil. La prueba de acceso de reserva ha funcionado. Ahora supón que ambos dispositivos dependen de la misma cuenta del proveedor de credenciales y que tampoco puede acceder a ella. La primera prueba no resuelve este segundo problema.

Haz un inventario de las dependencias en lugar de contar dispositivos:

La tabla sirve para planificar. Añade tus observaciones reales a un procedimiento interno. Un resultado en blanco significa que esa vía no se ha probado, por muy clara que sea la documentación del proveedor.

No uses «sin contraseña» para describir todo el proceso de recuperación. Una clave de acceso puede proteger una autenticación concreta, mientras que volver a entrar sigue dependiendo de una cuenta de proveedor, un buzón o una decisión administrativa.

Ensaya también la pérdida de acceso al proveedor de credenciales

Una clave sincronizada puede mejorar la disponibilidad, pero quizá tu compañero también necesite recuperar la cuenta del proveedor de sincronización. Comprueba qué permite hacer tu aplicación cuando ese sistema no está disponible, en vez de dar por hecho que otro dispositivo siempre aportará la credencial.

En esta parte del simulacro, considera inaccesibles todas las claves de acceso de Maya. Usa una identidad de prueba; no borres las credenciales de un administrador de producción para dar realismo al ejercicio. Sigue el procedimiento documentado desde un navegador nuevo y anota el primer requisito que no pueda cumplir.

Quizá pueda iniciar sesión con otro método y llegar a una página restringida para registrar credenciales. Quizá la aplicación solo permita claves de acceso y la remita a un proceso independiente de recuperación de identidad. O quizá un administrador pueda conceder un permiso limitado para registrar una nueva. Son diseños de recuperación muy diferentes.

El documento de FIDO sobre claves de acceso sincronizadas trata la autenticación alternativa y la recuperación junto con las credenciales sincronizadas. En la práctica, hay que examinar tanto el proceso del proveedor de credenciales como el de la aplicación. Que uno funcione no demuestra que el otro también lo haga, y «clave de acceso» no garantiza que puedas exportar credenciales entre los proveedores elegidos.

Pide a Maya que siga las instrucciones sin sus notas ni los marcadores habituales del navegador. Si el procedimiento está protegido por el mismo control de acceso que intenta superar, facilita las instrucciones necesarias por otro canal adecuado.

Comprueba también la dirección de entrega. Un mensaje de recuperación enviado a un buzón antiguo puede hacer fracasar un procedimiento bien diseñado. Aunque la dirección pertenezca a quien pide ayuda, eso no demuestra que la solicitud sea legítima si el supuesto incluye un posible acceso no autorizado al correo.

Decide quién puede autorizar el registro de una nueva credencial

La recuperación con ayuda administrativa deposita la confianza en quien aprueba la solicitud y en las pruebas que acepta. Asigna esa responsabilidad antes de activar el requisito y decide quién actuará cuando el administrador habitual no esté disponible.

Llega el mensaje de Maya: «He perdido el móvil y el portátil. ¿Podéis restablecer mi clave de acceso?». La aprobación debe seguir un procedimiento que el administrador pueda explicar y repetir. Un nombre visible convincente y una respuesta urgente por correo son motivos débiles para conceder una nueva vía de entrada a un espacio con información de candidatos.

Usa un canal independiente acorde con tu equipo y con el riesgo. Por ejemplo, el administrador puede llamar a Maya con unos datos de contacto que ya se hayan obtenido mediante un proceso fiable. Un número nuevo facilitado en la propia solicitud no es una confirmación independiente. Deja constancia de que se hizo la comprobación sin recopilar datos personales innecesarios en la solicitud de soporte.

La guía de NIST sobre autenticación y gestión de autenticadores diferencia la recuperación de la autenticación con los medios que aún quedan disponibles. Describe métodos de recuperación dentro de un marco de niveles de garantía, exige avisos de recuperación y trata el análisis de riesgos de los métodos propios de cada aplicación. Puedes usarla para examinar tu diseño sin afirmar que tu startup o tu proveedor cumple un nivel de garantía concreto.

Durante el simulacro, pide al administrador que explique exactamente qué permite su acción. ¿Registrar una credencial nueva, abrir toda la aplicación, restablecer otro factor o desactivar una política para todos? Prioriza una acción cuyo alcance y duración se ajusten a lo autorizado.

Después, considera que ese administrador no está disponible. ¿Quién más puede realizar la misma acción con los permisos adecuados? ¿Puede encontrar el procedimiento y verificar a Maya? Si no hay nadie, registra esa limitación de disponibilidad y decide si es aceptable antes de exigir la credencial.

No desactives la política del espacio de trabajo sin dejar constancia para que el ejercicio salga bien. Si relajar el requisito es una opción de emergencia explícita, documenta quién puede autorizarlo, qué acceso concede y cómo se restablecerá la política. Esa decisión merece su propio registro.

Comprueba qué sesiones siguen abiertas

Sustituir una credencial y poner fin al acceso existente son operaciones diferentes. El simulacro debe aclarar qué ocurre con las sesiones antiguas del navegador y con los tokens conectados, sobre todo si el dispositivo puede haber sido robado.

El modelo de credenciales y aserciones de WebAuthn vincula las credenciales de clave pública al servicio que autentica al usuario y especifica su validación durante la autenticación. Bien implementadas, esas propiedades sustentan la resistencia al phishing. No significan que cada petición posterior repita la autenticación ni que borrar una credencial cancele automáticamente una sesión ya emitida.

Vuelve al navegador original de Maya después de registrar la nueva credencial. Para mantener el ejercicio bajo control, representa el dispositivo inaccesible con otro navegador de prueba. ¿Sigue pudiendo leer datos? ¿Puede cambiar la configuración? ¿Eliminar la credencial antigua altera alguno de los resultados? Observa el comportamiento en lugar de suponer que «restablecer» implica revisar y cerrar todos los accesos de la cuenta.

Después, revisa las herramientas conectadas. Un token de API puede seguir funcionando porque es una credencial independiente. Una conexión con un asistente puede tener sus propios controles de autorización y revocación. Decide cuáles deben seguir disponibles durante un cambio de dispositivo normal y cuáles hay que revocar ante la sospecha de un acceso no autorizado.

Nuestra lista de comprobación para evaluar la baja mediante SSO plantea preguntas relacionadas sobre sesiones y conexiones. La distinción también importa aquí: cambiar la forma de autenticarse no demuestra, por sí solo, qué permisos o credenciales anteriores han dejado de funcionar.

Registra el resultado con precisión: se revocó la sesión del navegador antiguo, se eliminó la credencial perdida y se renovó un token concreto, si esas acciones ocurrieron realmente. «Cuenta recuperada» es demasiado ambiguo para que el siguiente administrador sepa si un atacante todavía podría conservar una sesión válida.

Decide la implantación a partir del simulacro

Exige claves de acceso cuando conozcas las vías de autenticación compatibles y hayas aceptado las limitaciones de recuperación que quedan. Un simulacro satisfactorio debe dejar un procedimiento utilizable, un administrador responsable y un registro de los accesos que siguen activos tras el cambio de credencial.

Recoge las pruebas de forma breve. Para cada caso, anota la situación inicial, la vía que se intentó, el resultado observado y el cambio necesario. Indica si el proceso dependió de una persona, un buzón, un proveedor o un dispositivo concretos. Corrige los pasos que fallen y vuelve a ensayarlos antes de ampliar el requisito.

Distingue el resultado técnico de la decisión. «La llave de reserva permitió autenticarse desde el portátil nuevo» es una observación. «Cada persona debe registrar una credencial de reserva que pueda usar por separado antes de la implantación» es una decisión de tu política. «Aceptamos esperar hasta que vuelva un administrador autorizado» es otra posible decisión, siempre que el equipo afectado lo entienda.

Durante la implantación puedes medir el tiempo necesario, las solicitudes de soporte y los intentos de registro abandonados. Son medidas de tu propio proceso. No necesitan una referencia sectorial inventada ni una promesa de que las claves de acceso reducirán la carga de soporte en un porcentaje determinado.

Por último, comunica qué debe hacer cada persona antes de activar el requisito y cómo pedir ayuda después. Explica dónde se gestionan las credenciales, qué vías de reserva admite el equipo y qué pedirá un administrador antes de autorizar una nueva. Un mensaje breve ligado a un procedimiento probado ayuda más que asegurar de forma genérica que nadie perderá el acceso.

Cómo funciona la recuperación de claves de acceso en Kit

La aplicación debe explicar sus límites de acceso y recuperación con suficiente claridad para poder ensayarlos. En Kit, la clave de acceso pertenece a la persona, mientras que una cuenta puede exigir que el navegador se verifique con una antes de abrir ese espacio de trabajo. Se trata del acceso del equipo al producto; el acceso al portal del candidato sigue otro proceso.

Antes de activar el requisito, el administrador que lo haga ya debe tener una clave de acceso. El ajuste requiere el permiso gestionar la seguridad, disponible para los roles Admin y Analista de seguridad. No hay una excepción general para el propietario. Revisa primero la tabla de cumplimiento de los miembros: el requisito entra en vigor inmediatamente, sin periodo de gracia ni implantación gradual incorporados.

El navegador debe tener registrada una verificación con clave de acceso en su sesión. Que alguien tenga una credencial registrada no demuestra que todos sus navegadores la hayan usado. Una vez verificada, la sesión puede cumplir el requisito durante toda su vigencia; la política no exige una nueva aserción en cada página. Una sesión autenticada mediante SAML obligatorio también puede satisfacer el requisito. La solidez de esa autenticación depende de la política del proveedor de identidad.

Si alguien que ya ha iniciado sesión pierde todas sus claves de acceso, un administrador de seguridad autorizado puede emitir un pase para volver a registrarlas. Kit lo envía directamente por correo al miembro. Abrir el enlace muestra una página de confirmación; al confirmar, el pase queda consumido y se abre un plazo de 15 minutos para registrar una nueva clave en esa cuenta. El pase permite un solo uso dentro de 24 horas, y emitir otro sustituye al anterior. La documentación sobre el requisito de claves de acceso explica el proceso.

Esta vía sigue exigiendo que el miembro haya iniciado sesión como el usuario al que corresponde el pase. No garantiza recuperar una identidad de Kit completamente inaccesible. El administrador debe verificar la solicitud por un canal independiente, y la entrega del correo sigue formando parte del proceso de confianza. Registrar una nueva clave tampoco revoca automáticamente las sesiones antiguas del navegador.

Los tokens de API y las conexiones MCP tienen otra limitación: comprueban si su usuario tiene una clave de acceso registrada, en lugar de realizar una aserción de WebAuthn. Al evaluar las herramientas conectadas, considera que ofrecen menos garantías que la verificación del navegador.

Ensaya estos límites antes de activar el ajuste. Empieza por la guía de configuración de claves de acceso, prueba después el registro de una nueva y revisa la seguridad de inicio de sesión con otro administrador autorizado. El resultado útil es una persona que pueda seguir el procedimiento de recuperación y un administrador que sepa exactamente qué acceso ha restablecido.