Passkeys o TOTP: resistir phishing cambia también la recuperación

Si la prioridad es proteger el acceso frente al phishing, una passkey ofrece una ventaja técnica sobre TOTP: las directrices de NIST sobre autenticadores explican que WebAuthn vincula la autenticación al dominio verificado, mientras que un código introducido manualmente puede retransmitirse desde una página falsa. Elegir una passkey también obliga a revisar cómo se recuperará la cuenta si se pierde el dispositivo.

TOTP suele añadirse como segundo factor a una contraseña; una passkey puede sustituir el inicio de sesión con contraseña. La comparación, por tanto, incluye tanto el acceso habitual como las rutas que quedan abiertas cuando falta una credencial: otra passkey, un código de recuperación, la cuenta del proveedor que sincroniza claves o la intervención del servicio.

La diferencia está en lo que recibe la página falsa

Una aplicación TOTP genera códigos temporales a partir de un secreto compartido con el servicio. El código acredita que quien inicia sesión dispone de ese secreto, pero la persona debe escribirlo en la página que tiene delante. Si esa página es una imitación, el atacante puede trasladar el código al servicio legítimo mientras siga siendo válido.

Con una passkey, el autenticador conserva una clave privada y el servicio guarda la clave pública correspondiente. Ante un desafío, el autenticador produce una respuesta que el servicio verifica sin recibir la clave privada ni pedir al usuario que copie un código. El navegador participa en la comprobación del dominio: una página alojada en otro dominio no puede obtener una respuesta válida para el servicio suplantado mediante el mismo engaño de pedir y reenviar un código.

La passkey puede activarse con un PIN o una comprobación biométrica local. Eso no significa que toda implantación de passkeys cumpla automáticamente una exigencia de dos factores: el servicio debe solicitar y comprobar la verificación del usuario para contar ese desbloqueo local como factor adicional.

Una matriz de amenazas para comparar los fallos

La protección contra una página falsa resuelve un ataque concreto. Otros fallos dependen de dónde se guarda la credencial, de quién puede activar un dispositivo y de cómo el servicio restablece el acceso:

• Phishing remoto: con TOTP, una página impostora puede pedir el código y usarlo en una sesión real. Una passkey vinculada al dominio legítimo impide esa retransmisión ordinaria de la respuesta de autenticación.
• Robo del dispositivo: tener el teléfono o la llave física no equivale necesariamente a poder activar la passkey; importan el PIN, la biometría o el bloqueo local configurado. También importa si el dispositivo robado conserva una sesión ya iniciada, porque esa sesión plantea un problema distinto al del inicio de sesión.
• Pérdida de acceso: si la única passkey está ligada a un aparato perdido, hará falta otra credencial registrada o recuperar la cuenta. Si desaparece el único generador TOTP y no hay copia del secreto, el titular también dependerá del procedimiento de respaldo del servicio.
• Sincronización y administrador comprometido: una clave que puede llegar a otros dispositivos facilita el reemplazo, pero añade la cuenta y la infraestructura del proveedor a la evaluación de seguridad. Un administrador con capacidad para incorporar credenciales o restablecer cuentas representa otra ruta de acceso que requiere controles propios.
• Navegador o autenticador alterado: la protección del protocolo presupone que ciertas partes del entorno funcionan correctamente. Un análisis académico de ataques contra FIDO2 evaluó un autenticador manipulado y una alteración de la confianza del navegador; encontró ataques viables que exigían más esfuerzo y recursos, mientras la resistencia al phishing se mantenía en gran medida.

Recuperar la cuenta puede reabrir la entrada vulnerable

Una cuenta que permite iniciar sesión con passkey y también volver a una contraseña más TOTP conserva una ruta susceptible de phishing. El marco de adopción de FIDO Alliance clasifica las passkeys como resistentes al phishing y los códigos TOTP y de recuperación como susceptibles; distingue además la seguridad del inicio de sesión de la del procedimiento para recuperar la cuenta.

La existencia de un respaldo sigue siendo necesaria. Una segunda passkey registrada antes de perder la primera puede mantener el acceso sin recurrir a un código, siempre que el servicio permita usarla. Cuando la recuperación pasa por correo, atención al cliente o un administrador, la cuestión es qué comprobación autoriza añadir una nueva credencial y cómo se informa al titular de ese cambio.

Para una organización, retirar TOTP de la pantalla habitual no basta si la mesa de ayuda puede restablecer la cuenta mediante una prueba más fácil de superar para un impostor. Para una persona, activar una passkey sin entender la recuperación puede convertir la pérdida de un dispositivo en un bloqueo prolongado. La ventaja frente al phishing depende, en ambos casos, de las rutas de acceso que permanecen disponibles.

Sincronización: menos dependencia del aparato, más del proveedor

Una passkey sincronizada puede estar disponible en otro dispositivo autorizado mediante el mismo proveedor de credenciales. Una passkey ligada a una llave de seguridad o a un dispositivo concreto no reaparece por esa vía: exige otra credencial inscrita o el proceso de recuperación del servicio. La diferencia afecta tanto a la continuidad del acceso como al control sobre dónde existe una copia de la clave.

El apartado de NIST sobre autenticadores sincronizables exige cifrar las claves exportadas y proteger el acceso a la infraestructura de sincronización; identifica también la recuperación de la cuenta del proveedor como una posible debilidad. Sincronizar facilita reemplazar un aparato, pero traslada parte de la decisión a la protección de esa cuenta, a las reglas para incorporar dispositivos y a la posibilidad de retirar los perdidos. Esa dependencia se examina también en la sincronización de passkeys.

TOTP tampoco implica necesariamente que el secreto viva en un solo teléfono: algunas aplicaciones permiten copiarlo o sincronizarlo. Eso mejora la continuidad, aunque obliga a proteger las copias y la cuenta que permite recuperarlas. La comparación útil es entre configuraciones concretas, no entre la idea de una passkey siempre recuperable y un código siempre aislado.

Compatibilidad y decisión de migración

El servicio debe admitir passkeys y el usuario necesita una forma de emplearlas en los equipos desde los que entra. La explicación de FIDO Alliance sobre passkeys distingue las sincronizadas de las ligadas a un dispositivo y describe el inicio de sesión en otro equipo mediante una passkey que permanece en el teléfono. Ese uso entre dispositivos no equivale a que una clave guardada con un proveedor aparezca automáticamente en otro.

Si una cuenta ofrece ambos métodos y dispone de un respaldo utilizable, elegir passkey reduce la exposición al phishing del acceso habitual. TOTP conserva valor cuando el servicio todavía no admite passkeys o cuando se necesita un segundo factor para una cuenta que usa contraseña, con el límite de que el código puede capturarse en una página falsa.

En un despliegue organizativo, la decisión incluye qué dispositivos y proveedores se aceptan, cómo se registra una credencial adicional y quién puede autorizar la recuperación. Esas reglas determinan si la mejora del inicio de sesión se mantiene cuando alguien pierde su dispositivo o solicita volver a entrar.

Lee también:

• Passkeys o contraseñas: el riesgo cambia al proveedor que las sincroniza
• EE. UU. creó 162.000 empleos: la Fed recupera margen para subir tipos
• El phishing esconde palabras con Unicode: llegó a millones de correos al día