WebAuthn: Implementación de Passkeys, autenticación sin contraseñas y validación criptográfica

Todos conocemos la promesa de las Passkeys: erradicar las contraseñas débiles y neutralizar de raíz los ataques de phishing mediante criptografía de clave pública. Sin embargo, para muchos equipos de desarrollo y administradores de sistemas, el verdadero freno a su adopción es el pánico a implementarlo en el backend, imaginando una pesadilla matemática de curvas elípticas, formatos binarios y firmas complejas. En este episodio desmitificamos la implementación de WebAuthn del lado del servidor (Relying Party) y demostramos que, lejos de ser un laberinto incomprensible, se trata de un flujo estructurado, ordenado y perfectamente abordable. En este análisis detallado exploramos: • Los tres actores de WebAuthn y la separación estricta de responsabilidades: Autenticador: El enclave seguro (chip TPM, Secure Enclave en smartphones o llaves físicas FIDO2 USB) que custodia la clave privada y firma desafíos sin que esta abandone jamás el hardware. Cliente (Navegador web): El puente que gestiona la comunicación y la interacción con el usuario (PIN, huella o Face ID). Servidor (Relying Party): Quien emite los desafíos (challenges) y verifica matemáticamente las respuestas sin interactuar nunca directamente con el hardware del autenticador. • Inmunidad contra el phishing gracias al RP ID: Cómo el navegador vincula criptográficamente la credencial al dominio exacto de la barra de direcciones (ejemplo.com), bloqueando instantáneamente cualquier ataque de Reverse Proxy o dominio similar (ejemplo1.com) sin necesidad de lógica adicional en el backend. • Flujo de Registro (Attestation) y validación quirúrgica: Generación de desafíos (challenges) criptográficamente seguros de un solo uso en el servidor. El error crítico en producción al validar el origen: Por qué jamás se deben usar funciones de texto como 'startsWith' o 'includes' y la necesidad de una comprobación exacta y estricta para evitar bypasses de subdominio. Almacenamiento seguro en base de datos: Clave pública, ID de la credencial y contador de firmas. • Flujo de Autenticación (Assertion): Verificación matemática ligera mediante desafío-respuesta sobre la clave pública existente y actualización del contador de firmas. • Passkeys Sincronizadas vs. Ligadas a Hardware: Por qué configurar 'attestation: none' es la recomendación estándar de la industria salvo en entornos de defensa o banca ultra-regulada, preservando la privacidad y evitando mantener complejas bases de datos de certificados de fabricantes. El contador de firmas (signCount): Por qué en Passkeys sincronizadas (iCloud Keychain, Google Password Manager) el contador suele fijarse en 0 para evitar desincronizaciones entre dispositivos, y la importancia de no bloquear usuarios legítimos por este motivo frente a llaves FIDO2 físicas donde sí incrementa. • La regla de oro en arquitectura: No reinventar la rueda: Prohibición absoluta de parsear binarios CBOR a mano; delegación en librerías auditadas por la comunidad (como SimpleWebAuthn para Node.js o WebAuthn4J para Java). • La trampa de la puerta trasera: De nada sirve blindar la entrada con WebAuthn si el flujo de recuperación de cuenta sigue dependiendo de un enlace mágico enviado a un correo potencialmente comprometido. En tus plataformas y desarrollos, ¿has dado ya el salto a WebAuthn/Passkeys para autenticación principal o doble factor (2FA), o sigue pesando el miedo a gestionar flujos de recuperación de cuenta y soporte para usuarios con múltiples dispositivos? #Ciberseguridad #WebAuthn #Passkeys #FIDO2 #Autenticacion #DevSecOps #AppSec #DesarrolloWeb #Backend #Sysadmin