Passwords y MFA: Migrando a Passkeys sin Romper tu Recuperacion
Las passkeys reducen phishing y fatiga de MFA, pero migrar mal te deja fuera. Aprende a planificar fallback, dispositivos y roaming sin agujeros.
La primera vez que un cliente me llamo a las 23h porque el CFO habia tirado el iPhone a la piscina y perdido acceso a todo, quedo claro que una passkey sin plan de recuperacion es solo una forma elegante de bloquearte fuera. Las passkeys resuelven el problema correcto: matan la reutilizacion de password, el phishing inverso y la mayoria del MFA fatigue que dispara incidentes hoy. Pero una migracion mal planificada crea una clase nueva de incidente: usuario legitimo bloqueado, sin canal de reset confiable, con el helpdesk convirtiendose en vector de ingenieria social. El punto aqui es tratar la passkey como proyecto de identidad, no como boton nuevo en el login.
Tecnicamente, una passkey es un par de claves WebAuthn (normalmente ES256 o EdDSA) vinculado a un origen. La clave privada vive en un authenticator: Secure Enclave en iPhone, TPM 2.0 en Windows Hello, StrongBox en Android, o un token externo tipo YubiKey 5C NFC. El servidor guarda solo la clave publica y el credentialId. Eso significa que el phishing clasico no funciona: la firma esta atada al RP ID (dominio). En pruebas contra clones con evilginx2, la passkey simplemente no firma para el dominio incorrecto, mientras TOTP cae en el 100% de los casos con proxy reverso. Detalles practicos en Pentest Web desde Cero: Montando un Lab Seguro con DVWA, Juice Shop y Burp Suite y en Phishing en Red Team Autorizado: Plantillas, GoPhish y Limites Eticos.
El riesgo real no es el protocolo, es la recuperacion. Investiga como tu proveedor (Apple iCloud Keychain, Google Password Manager, 1Password, Bitwarden) sincroniza credenciales y cual es la ceremonia de restore. Apple exige passcode del dispositivo mas un contacto de recuperacion o una clave de recuperacion de 28 caracteres. Google usa el screen lock del dispositivo previo. Si deshabilitas SMS y correo como fallback sin configurar esto, perdiste. Documenta el flujo en tu modelo de amenaza personal antes de migrar; OPSEC para Investigadores de Seguridad: Modelo de Amenaza Personal tiene el esqueleto que uso con clientes de alto riesgo y periodistas.
Para equipos corporativos, la regla que aplico es dos authenticators fisicos por usuario critico (ej: YubiKey 5C + YubiKey 5 Nano), enrolados el mismo dia, uno guardado en caja fuerte fisica. En IdPs como Entra ID, Okta o Google Workspace, configura attestation policy exigiendo authenticators certificados FIDO2 L1+ para cuentas privilegiadas. Deshabilita enrollment self-service sin revision para grupos admin. Para cuentas personales de investigadores, combina passkey sincronizada (comodidad) con security key fisica (resiliencia). El playbook de hardening de estacion en Hardening de Windows 11 para Estaciones de Trabajo de Alto Riesgo cubre el endpoint, y Hardening de macOS: Lockdown Mode, MDM y Reduccion de Superficie el equivalente Apple.
El helpdesk es donde ocurren el 80% de los bypasses. MGM, Caesars y Cloudflare ya documentaron el patron: atacante llama, finge perdida de dispositivo, helpdesk resetea MFA. Con passkey el vector cambia pero no desaparece, se convierte en reset de passkey. Implementa verificacion out-of-band obligatoria: video call con documento, o aprobacion de gerente via canal separado. Loguea toda operacion de reset con retencion de 1 ano y alerta SIEM. Si corres reglas Sigma, escribe una para 'credential reset fuera de horario laboral seguido de login desde geo nueva' - ejemplo concreto en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion y patrones de hunting en Hunting de Living-off-the-Land Binaries en Windows con KQL.
La password desaparece? No tan rapido. En la practica, manten password fuerte (>=20 chars, generada por gestor) como respaldo en cuentas que aun no soportan passkey-only, y deshabilita SMS siempre que puedas. Para cuentas que ya soportan (Google, Microsoft, GitHub, Apple, Cloudflare), activa passkey-only despues de 30 dias de prueba paralela. Guarda codigos de backup impresos en caja fuerte, separados de los authenticators. Para cripto y boveda de passwords, Cripto de Disco y Backups: VeraCrypt, LUKS y Estrategia 3-2-1 Resiliente muestra como aplicar 3-2-1 sin caer en copia unica que se vuelve punto unico de falla.
Errores comunes que vi en auditoria: 1) admin global con solo una passkey en celular personal; 2) recovery email apuntando a cuenta sin MFA; 3) BitLocker recovery key guardada 'en la nube' de la misma cuenta que intentas recuperar - loop perfecto; 4) helpdesk autorizado a deshabilitar MFA por ticket, sin aprobacion de gerente; 5) passkey 'sincronizada' marcada como hardware-bound en el inventario. Audita esto con un ejercicio purple team trimestral, igual al ciclo en Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue. En red team autorizado, esos son los primeros caminos que probamos despues de initial access.
Takeaway practico: el proximo viernes, abre tus 5 cuentas mas criticas (correo primario, banco, gestor de passwords, IdP corporativo, registrador de dominio). Para cada una: registra 2 passkeys en authenticators diferentes, imprime codigos de backup, valida que puedes loguear sin el dispositivo principal, y elimina SMS como fallback. Documenta el procedimiento de recuperacion en sobre sellado. Si no logras hacerlo en 90 minutos por cuenta, aun no estas listo para apagar la password - y esta bien, es parte del plan.