Senhas e MFA: Migrando para Passkeys sem Quebrar sua Recuperacao

A primeira vez que um cliente me ligou as 23h porque o CFO tinha jogado o iPhone na piscina e perdido acesso a tudo, ficou claro que passkey sem plano de recuperacao e so um modo elegante de se trancar pra fora. Passkeys resolvem o problema certo: matam reuso de senha, phishing reverso e a maior parte do MFA fatigue que dispara incidentes hoje. Mas a migracao mal planejada cria uma classe nova de incidente: usuario legitimo bloqueado, sem canal de reset confiavel, com helpdesk virando vetor de engenharia social. Este post trata passkey como projeto de identidade, nao como botao novo no login, e percorre a cadeia protocolo, recuperacao, enrollment de time, helpdesk, deteccao e checklist na ordem em que ela realmente quebra em producao.

O que e tecnicamente uma passkey

Uma passkey e um par de chaves WebAuthn/FIDO2, normalmente ES256 (P-256) ou EdDSA (Ed25519), gerado no registro e amarrado a uma origem. A chave privada nunca sai do authenticator: Secure Enclave no iPhone, TPM 2.0 atras do Windows Hello, StrongBox no Android, ou um token externo tipo YubiKey 5C NFC. O servidor (a relying party) guarda so a chave publica, o credentialId e um contador de assinaturas. No login o servidor manda uma challenge aleatoria, o authenticator assina depois de um gesto de user-presence ou user-verification, e o servidor verifica a assinatura contra a chave publica armazenada. Nao ha segredo compartilhado pra phishar, vazar de um banco ou capturar com proxy reverso.

Por que o phishing falha no protocolo

O valor decisivo e a amarracao ao RP ID (o dominio registrado). O navegador so assina quando a origem que chama bate com o RP ID registrado, e a assinatura cobre um clientDataHash sobre origem e challenge. Em testes contra um clone com evilginx2, a passkey simplesmente nao assina pro dominio errado, enquanto TOTP e proxeado em 100% dos casos porque o usuario digita o codigo numa pagina identica. Essa visao de atacante voce reproduz em lab como em Phishing em Red Team Autorizado: Templates, GoPhish e Ressalvas Eticas, com o setup web geral em Pentest Web do Zero: Montando um Lab Seguro com DVWA, Juice Shop e Burp Suite.

O risco real: a recuperacao, nao o protocolo

Pesquise como seu provedor sincroniza credenciais e qual e a cerimonia de restore. Apple iCloud Keychain exige device passcode mais um contato de recuperacao ou chave de 28 caracteres. Google Password Manager usa o screen lock do dispositivo previo. Gerenciadores como 1Password e Bitwarden sincronizam a passkey via seu cofre, cujo segredo mestre vira entao a joia da coroa. O erro que tranca gente pra fora: desabilitar SMS e e-mail como fallback sem configurar antes o novo caminho. Documente o fluxo em modelo de ameaca pessoal antes de migrar; OPSEC para Pesquisadores de Seguranca: Modelo de Ameaca Pessoal tem o esqueleto que uso com clientes de alto risco e jornalistas.

Sincronizada vs presa ao dispositivo: o debate errado

Uma passkey sincronizada e comoda e sobrevive a perda do dispositivo porque vive na nuvem do provedor; a seguranca dela vale exatamente o que vale a recuperacao de conta desse provedor. Uma passkey presa ao dispositivo (token hardware, ou chave de plataforma sem sync) nunca sai do silicio e nao sobrevive a um dispositivo perdido sem uma segunda copia. A resposta madura nao e ou um ou outro: para contas pessoais de pesquisador, combine passkey sincronizada por conveniencia com security key fisica por resiliencia. Nunca confunda uma passkey sincronizada com uma hardware-bound no inventario: a attestation devolvida no registro te diz o que voce realmente tem.

Rollout de time: dois authenticators, politica dura

Minha regra pra usuarios criticos: dois authenticators fisicos (ex: YubiKey 5C + YubiKey 5 Nano), enrollados no mesmo dia, um guardado em cofre fisico. Em IdPs como Entra ID, Okta ou Google Workspace, configure attestation policy exigindo authenticators certificados FIDO2 L1+ para contas privilegiadas, e desabilite enrollment self-service sem revisao para grupos admin. Exija user verification (userVerification: required), nao so user presence. O playbook de estacao em Hardening de Windows 11 para Estacoes de Trabalho de Alto Risco cobre o endpoint, e Hardening de macOS: Lockdown Mode, MDM e Reducao de Superficie o equivalente Apple.

O vetor helpdesk: onde 80% dos bypasses acontecem

MGM, Caesars e Cloudflare ja documentaram o mesmo padrao: atacante liga, finge perda de dispositivo, helpdesk reseta MFA. Com passkey o vetor nao some, vira reset de passkey. Implemente verificacao out-of-band obrigatoria: video call com documento, ou aprovacao de gestor via canal separado e predefinido - nunca o mesmo canal por onde veio o pedido. Adicione um atraso pra resets de alto risco e notifique o titular real por um segundo fio antes de o reset valer. Toda operacao de reset e logada, com retencao de 1 ano e alerta SIEM.

Deteccao: anomalias de reset em Sigma

Um reset fora de horario seguido de login de geo nova em minutos e sinal em texto claro. Se voce roda Sigma, escreva uma regra pra reset de credential/authenticator seguido de login de ASN divergente ou delta de viagem impossivel. Exemplo concreto em Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao, e padroes de hunting pos-acesso em Hunting de Living-off-the-Land Binaries no Windows com KQL. Alerte no enrollment de um authenticator novo logo apos um reset: essa e a jogada de persistencia classica do atacante.

Desligar a senha? O caminho por fases

Nao tao rapido. Na pratica, mantenha senha forte (>=20 chars, gerada por gerenciador) como backup em contas que ainda nao suportam passkey-only, e desabilite SMS sempre que possivel. Para contas que ja suportam (Google, Microsoft, GitHub, Apple, Cloudflare), ative passkey-only so depois de 30 dias de teste paralelo. Guarde codigos de backup impressos em cofre, separados dos authenticators. Para cripto e cofres de senha, Cripto de Disco e Backups: Veracrypt, LUKS e Estrategia 3-2-1 Resiliente mostra como aplicar 3-2-1 sem cair em copia unica que vira ponto unico de falha.

Erros comuns que vi em auditoria

Os mesmos cinco voltam sempre: 1) admin global com so uma passkey num celular pessoal; 2) recovery email apontando pra conta sem MFA; 3) BitLocker recovery key salva na nuvem da mesma conta que voce esta tentando recuperar - o loop perfeito; 4) helpdesk autorizado a desabilitar MFA por chamado sem aprovacao de gestor; 5) passkey sincronizada marcada como hardware-bound no inventario. Audite isso com um exercicio purple team trimestral, igual ao ciclo em Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue. Em red team autorizado, esses sao os primeiros caminhos que testamos depois de initial access.

Checklist de migracao

Por conta critica, nesta ordem: (a) registrar dois authenticators em hardware diferente; (b) conferir a attestation, sincronizada ou presa ao dispositivo; (c) imprimir codigos de backup e selar em cofre; (d) fazer um ensaio de recuperacao sem o dispositivo principal; (e) remover o fallback SMS; (f) apontar o recovery email pra uma conta que tambem tenha MFA; (g) documentar o procedimento de reset e alertar no SIEM. So quando os sete estao verdes a conta esta realmente migrada, nao no momento em que o novo login funciona.

Credenciais descobriveis e login sem usuario

Uma resident key (credencial descobrivel) guarda o mapeamento do user-handle dentro do proprio authenticator, entao o login funciona sem digitar usuario antes: via Conditional UI (autofill WebAuthn), o navegador oferece a passkey certa diretamente. E comodo mas tem limite de capacidade - YubiKeys antigos guardam so cerca de 25 resident keys, e um slot cheio causa falhas silenciosas de enrollment dificeis de debugar num rollout. Em dispositivos compartilhados ou quiosque, credenciais descobriveis sao ainda um risco de privacidade porque uma lista de contas fica visivel no aparelho. Escolha conscientemente entre resident (sem usuario) e non-resident (credencial do lado servidor) conforme o modelo de ameaca do dispositivo, em vez de aceitar o default.

Cross-device: o transporte hibrido via CTAP 2.2

O caso real mais comum - logar num desktop com a passkey do celular - roda sobre o transporte hibrido (antigo caBLE): o desktop mostra um QR, o celular escaneia e confirma via checagem de proximidade BLE que os dois dispositivos estao fisicamente perto. Esse requisito de proximidade e justamente por que passkeys nao sao phishadas remotamente como um OTP de telefone. Teste explicitamente o fluxo cross-device no seu rollout, porque ele costuma falhar por Bluetooth desativado, redes corporativas restritivas ou apps authenticator desatualizados - e um usuario que nao consegue executar o unico caminho de recuperacao fica tao trancado quanto um sem backup.

FAQ: Passkeys sao resistentes a quantico?

Nao, ES256 e EdDSA sao curvas elipticas classicas e nao resistem a um computador quantico criptograficamente relevante. Na pratica importa menos do que parece: passkeys usam challenge-response, entao nenhum segredo reutilizavel trafega no fio pra ser gravado e quebrado depois. A FIDO Alliance ja trabalha em attestation e assinaturas PQC; do lado da migracao nada muda pra voce assim que o firmware do authenticator e os navegadores entregarem isso.

FAQ: E se eu perder todos os dispositivos de uma vez?

E exatamente pra isso que existe o envelope selado: codigos de backup impressos mais uma terceira chave de hardware so-offline em cofre ou cofre de banco resolvem o cenario de perda total. No nivel do provedor, o contato de recuperacao (Apple) ou um reset de admin de negocio via canais out-of-band verificados e sua ultima volta. Se seu unico caminho de recuperacao e SMS pra um SIM perdido, voce nao tem recuperacao, voce tem a ilusao dela.

Conclusao e takeaway pratico

Na proxima sexta, abra suas 5 contas mais criticas (email primario, banco, gerenciador de senhas, IdP corporativo, registrar de dominio). Para cada uma: registre 2 passkeys em authenticators diferentes, imprima codigos de backup, valide que voce consegue logar sem o dispositivo principal, e remova SMS como fallback. Documente o procedimento de recuperacao num envelope selado. Se nao consegue fazer isso em 90 minutos por conta, voce ainda nao esta pronto pra desligar a senha - e tudo bem, faz parte do plano. Passkeys sao um ganho enorme de seguranca, mas so quando o caminho de recuperacao e levado tao a serio quanto o login em si.