Inicio de sesión resistente al phishing con WebAuthn y passkeys

Qué es

La Web Authentication API permite que una aplicación web cree y utilice credenciales de clave pública. En el registro, navigator.credentials.create() pide a un autenticador (el propio de la plataforma, que se desbloquea con biometría o PIN, o una llave de seguridad externa) que genere un par de claves; el servidor, denominado relying party (parte confiable), almacena la clave pública junto con la cuenta. En el inicio de sesión, navigator.credentials.get() transmite un desafío (challenge) generado por el servidor; tras el consentimiento del usuario, el autenticador lo firma con la clave privada y el servidor verifica la firma con la clave pública almacenada. La especificación asocia cada credencial a un identificador de la parte confiable (RP ID), una cadena de dominio que por defecto es el dominio efectivo del origen y que solo puede sustituirse por un sufijo de dominio registrable de este. Una credencial solo puede usarse con la misma entidad, identificada por su RP ID, con la que se registró, y los datos del cliente cubiertos por la firma incluyen el origen. Las passkeys son credenciales WebAuthn que son detectables (el autenticador guarda la clave privada y el identificador de usuario, por lo que no hace falta escribir antes un nombre de usuario) y que, en muchas implementaciones, el proveedor de la plataforma sincroniza entre los dispositivos del usuario. MDN señala que en la web las passkeys se implementan con esta API.

Por qué importa

Las contraseñas y los códigos de un solo uso pueden introducirse en una página de phishing y ser retransmitidos. Así resume MDN la defensa: un atacante que crea un sitio de inicio de sesión falso no puede iniciar sesión como el usuario, porque la firma cambia con el origen del sitio web. El servidor no guarda ningún secreto reutilizable, de modo que, si se filtra la tabla de credenciales, solo quedan expuestas claves públicas.

Cómo aplicarlo

• Utilice una biblioteca de servidor mantenida para las ceremonias de registro y de aserción; verifique el desafío, el origen, el hash del RP ID y la firma, y compruebe el contador de firmas cuando el autenticador lo proporcione.
• Elija el RP ID con criterio (el dominio registrable, si varios subdominios comparten cuentas) y manténgalo estable; cambiarlo invalida todas las credenciales.
• Permita varias credenciales por cuenta y diseñe la recuperación de la cuenta de modo que no sea más débil que la passkey a la que sustituye.
• Para el inicio de sesión sin contraseña, solicite credenciales detectables y verificación de usuario; si el modelo de cuentas aún no está preparado, ofrezca primero las passkeys como segundo factor.
• Almacene el identificador de la credencial, la clave pública, el contador de firmas y los transportes; la clave privada nunca llega al servidor.

Trampas

Los flujos de recuperación (enlaces de restablecimiento por correo, servicios de soporte) pasan a ser el objetivo del phishing cuando el factor principal ya resiste este tipo de ataque. La atestación es opcional, y MDN aconseja a las partes confiables no mantener listas de autenticadores permitidos. Las passkeys sincronizadas trasladan la confianza a la cuenta de plataforma del usuario; las credenciales ligadas al dispositivo en llaves de seguridad no se sincronizan y requieren una segunda credencial registrada. Los cuadros de diálogo del navegador y de la plataforma varían; pruebe en los dispositivos que usan sus usuarios.