Passwords y MFA: Migrando a Passkeys sin Romper tu Recuperacion

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. Este articulo trata la passkey como proyecto de identidad, no como boton nuevo en el login, y recorre la cadena protocolo, recuperacion, enrollment de equipo, helpdesk, deteccion y checklist en el orden en que realmente se rompe en produccion.

Que es tecnicamente una passkey

Una passkey es un par de claves WebAuthn/FIDO2, normalmente ES256 (P-256) o EdDSA (Ed25519), generado en el registro y atado a un origen. La clave privada nunca sale del authenticator: Secure Enclave en iPhone, TPM 2.0 detras de Windows Hello, StrongBox en Android, o un token externo tipo YubiKey 5C NFC. El servidor (la relying party) guarda solo la clave publica, el credentialId y un contador de firmas. En el login el servidor envia una challenge aleatoria, el authenticator la firma tras un gesto de user-presence o user-verification, y el servidor verifica la firma contra la clave publica almacenada. No hay secreto compartido que phishear, filtrar de una base de datos o capturar con un proxy reverso.

Por que el phishing falla en el protocolo

El valor decisivo es el vinculo con el RP ID (el dominio registrado). El navegador solo firma cuando el origen que llama coincide con el RP ID registrado, y la firma cubre un clientDataHash sobre origen y challenge. En pruebas contra un clon con evilginx2, la passkey simplemente no firma para el dominio incorrecto, mientras TOTP se proxya el 100% de las veces porque el usuario tipea el codigo en una pagina identica. Esa vista de atacante la reproduces en un lab como en Phishing en Red Team Autorizado: Plantillas, GoPhish y Limites Eticos, con el montaje web general en Pentest Web desde Cero: Montando un Lab Seguro con DVWA, Juice Shop y Burp Suite.

El riesgo real: la recuperacion, no el protocolo

Investiga como tu proveedor sincroniza credenciales y cual es la ceremonia de restore. Apple iCloud Keychain exige passcode del dispositivo mas un contacto de recuperacion o una clave de 28 caracteres. Google Password Manager usa el screen lock del dispositivo previo. Gestores como 1Password y Bitwarden sincronizan la passkey via tu boveda, cuyo secreto maestro se vuelve entonces la joya de la corona. El error que bloquea gente: deshabilitar SMS y correo como fallback sin configurar antes el nuevo camino. Documenta el flujo en un 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.

Sincronizada vs atada al dispositivo: el debate equivocado

Una passkey sincronizada es comoda y sobrevive a la perdida del dispositivo porque vive en la nube del proveedor; su seguridad es exactamente tan buena como la recuperacion de cuenta de ese proveedor. Una passkey atada al dispositivo (token hardware, o clave de plataforma sin sync) nunca sale del silicio y no sobrevive a un dispositivo perdido sin una segunda copia. La respuesta madura no es o uno u otro: para cuentas personales de investigador, combina passkey sincronizada por comodidad con security key fisica por resiliencia. Nunca confundas una passkey sincronizada con una hardware-bound en tu inventario: la attestation devuelta en el registro te dice que tienes de verdad.

Rollout de equipo: dos authenticators, politica dura

Mi regla para usuarios criticos: dos authenticators fisicos (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, y deshabilita enrollment self-service sin revision para grupos admin. Exige user verification (userVerification: required), no solo user presence. El playbook 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 vector helpdesk: donde ocurren el 80% de los bypasses

MGM, Caesars y Cloudflare documentaron el mismo patron: atacante llama, finge perdida de dispositivo, helpdesk resetea MFA. Con passkey el vector 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 y predefinido - nunca el mismo canal por donde entro el pedido. Agrega una demora para resets de alto riesgo y notifica al titular real por un segundo hilo antes de que el reset surta efecto. Toda operacion de reset se loguea, con retencion de 1 ano y alerta SIEM.

Deteccion: anomalias de reset en Sigma

Un reset fuera de horario seguido de un login desde geo nueva en minutos es una senal en texto claro. Si corres Sigma, escribe una regla para reset de credencial/authenticator seguido de login desde ASN divergente o delta de viaje imposible. Ejemplo concreto en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion, y patrones de hunting posteriores al acceso en Hunting de Living-off-the-Land Binaries en Windows con KQL. Alerta sobre enrollment de un authenticator nuevo poco despues de un reset: esa es la jugada de persistencia clasica del atacante.

Apagar la password? El camino por fases

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. En cuentas que ya lo soportan (Google, Microsoft, GitHub, Apple, Cloudflare), activa passkey-only recien 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

Los mismos cinco vuelven siempre: 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 - el 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.

Checklist de migracion

Por cada cuenta critica, en este orden: (a) registrar dos authenticators en hardware distinto; (b) verificar la attestation, sincronizada o atada al dispositivo; (c) imprimir codigos de backup y sellarlos en caja fuerte; (d) hacer un ensayo de recuperacion sin el dispositivo principal; (e) quitar el fallback SMS; (f) apuntar el recovery email a una cuenta que tambien tenga MFA; (g) documentar el procedimiento de reset y alertarlo en el SIEM. Solo cuando los siete estan en verde la cuenta esta realmente migrada, no en el momento en que el nuevo login funciona.

Credenciales descubribles y login sin usuario

Una resident key (credencial descubrible) guarda el mapeo del user-handle dentro del propio authenticator, asi el login funciona sin tipear usuario antes: via Conditional UI (autofill WebAuthn) el navegador ofrece la passkey correcta directamente. Es comodo pero tiene limite de capacidad - los YubiKeys viejos guardan solo unas 25 resident keys, y un slot lleno causa fallos silenciosos de enrollment dificiles de debuggear en un rollout. En dispositivos compartidos o kiosco, las credenciales descubribles son ademas un riesgo de privacidad porque una lista de cuentas queda visible en el equipo. Elige a conciencia entre resident (sin usuario) y non-resident (credencial del lado servidor) segun el modelo de amenaza del dispositivo, en vez de aceptar el default.

Cross-device: el transporte hibrido sobre CTAP 2.2

El caso real mas comun - loguear en un desktop con la passkey del celular - corre sobre el transporte hibrido (antes caBLE): el desktop muestra un QR, el celular lo escanea y confirma via un chequeo de proximidad BLE que ambos dispositivos estan fisicamente cerca. Ese requisito de proximidad es justo por que las passkeys no se phishean en remoto como un OTP telefonico. Prueba explicitamente el flujo cross-device en tu rollout, porque suele fallar por Bluetooth deshabilitado, redes corporativas restrictivas o apps authenticator desactualizadas - y un usuario que no puede ejecutar el unico camino de recuperacion queda tan bloqueado como uno sin backup.

FAQ: Son las passkeys resistentes a lo cuantico?

No, ES256 y EdDSA son curvas elipticas clasicas y no resisten a un computador cuantico criptograficamente relevante. En la practica importa menos de lo que parece: las passkeys usan challenge-response, asi que no viaja por la red ningun secreto reutilizable que grabar y romper despues. La FIDO Alliance ya trabaja en attestation y firmas PQC; del lado de la migracion no cambia nada para ti una vez que el firmware del authenticator y los navegadores lo entreguen.

FAQ: Y si pierdo todos los dispositivos a la vez?

Para eso existe el sobre sellado: codigos de backup impresos mas un tercer hardware key solo-offline en caja fuerte o cofre bancario resuelve el escenario de perdida total. A nivel proveedor, el contacto de recuperacion (Apple) o un reset de admin de negocio via canales out-of-band verificados es tu ultima via de regreso. Si tu unico camino de recuperacion es SMS a una SIM perdida, no tienes recuperacion, tienes la ilusion de ella.

Conclusion y 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. Las passkeys son una ganancia enorme de seguridad, pero solo cuando el camino de recuperacion se toma tan en serio como el login mismo.