Passkeys não bastam: entregue sessões vinculadas ao dispositivo em 90 dias

Passkeys mataram a maior parte do phishing de senha. Os atacantes se adaptaram. Eles pararam de mirar na sua tela de login e começaram a roubar aquilo em que você confia mais do que em senhas: tokens de sessão de longa duração. O Chrome está lançando sessões vinculadas ao dispositivo, e o OAuth finalmente tem uma abordagem prática de prova de posse. Se você não planejar isso nos próximos 90 dias, estará, na prática, reservando orçamento para reclamações por sequestro de contas.

O que acabou de mudar (e por que isso importa)

Dois sinais chegaram de uma vez. Primeiro, o Chrome começou a adotar o que chama de sessões vinculadas ao dispositivo (amplamente apontadas como a defesa no nível do navegador mais forte até agora contra sequestros de conta). Em outras palavras: uma chave gerenciada pelo navegador vincula a sessão a um dispositivo específico, de modo que um cookie roubado não possa ser reutilizado em outro lugar. Segundo, novas pesquisas expuseram armadilhas em implantações reais de passkeys — engenharia social esperta e brechas nos fluxos de recuperação que contornam completamente o WebAuthn. Juntas, elas confirmam o que a sua fila de incidentes já sabe: passkeys reforçam a etapa inicial, mas quem decide o jogo são os tokens.

Nada disso é teórico. Kits de phishing com proxy reverso (Evilginx e afins) e infostealers de prateleira têm como alvo cookies de sessão justamente porque eles contornam 2FA e passkeys. Pergunte a qualquer SaaS em escala: a reutilização de sessões roubadas supera o phishing clássico de senha por ampla margem. Passkeys não são o estado final; sessões vinculadas ao dispositivo são.

Atualize seu modelo de ameaças para 2026

• Comportamento principal do adversário: Replay de sessões e refresh tokens roubados obtidos via malware, proxies reversos ou SDKs de terceiros mal configurados. Eles evitam completamente a sua camada de autenticação.
• Onde você está vulnerável: Tempos de vida longos de sessão, refresh tokens utilizáveis de qualquer dispositivo, rotação frouxa e caminhos de recuperação (fluxos de suporte por email/SMS) que criam novas sessões agnósticas ao dispositivo.
• Por que agora: As sessões vinculadas ao dispositivo do Chrome começam a fechar a brecha de replay no lado do cliente. No lado do servidor, o DPoP do OAuth oferece hoje uma forma neutra em relação a fornecedor para vincular tokens a uma chave por dispositivo. Você não precisa esperar recursos de navegador amadurecerem.

Um framework de decisão: o que entregar primeiro

Trate isso como um problema de sequenciamento, não um debate de padrões. Use sua composição de tráfego e o risco para definir a ordem.

• Composição de tráfego: Se 55–70% das suas sessões estão no Chrome, planeje aproveitar sessões vinculadas ao dispositivo assim que chegarem à versão estável. Mas não estacione no cronograma de um fornecedor — implemente prova de posse agora com DPoP para todos os navegadores modernos.
• Superfície do app: SPAs e apps nativos podem adotar DPoP imediatamente. Sites tradicionais renderizados no servidor ainda podem vincular a emissão de refresh/token a uma chave por dispositivo e exigir prova de posse durante a renovação.
• Perfil de cliente: Clientes enterprise atrás de proxies frágeis? Faça rollout atrás de um feature flag e tenha fallback elegante. Tráfego consumidor em escala? Priorize rotação mais rápida e telemetria para matar a reutilização de tokens.
• Recuperação e suporte: Se a sua central de ajuda consegue criar uma sessão sem vinculação ao dispositivo, atacantes também conseguem. Corrija a recuperação em paralelo a qualquer trabalho de token.

O plano 30‑60‑90

Dia 0–30: Pare de emitir tokens bearer que você não consegue defender

• Faça inventário e encurte: Enumere todo token que você emite (cookies de sessão, tokens de API, refresh tokens). Defina max‑age agressivo para access tokens (10–15 minutos) e exija rotação para cookies de sessão ao menos a cada poucas horas. Use o prefixo __Host‑, HttpOnly, Secure, SameSite=Strict onde houver compatibilidade.
• Elimine renovações deslizantes sem prova: Renovações deslizantes (sliding) só devem ocorrer se o cliente puder provar que é o mesmo dispositivo que obteve o token inicialmente.
• Adicione telemetria de roubo: Faça log de um ID de chave de vinculação com cada token (placeholder por ora), registre user agent, plataforma e geolocalização aproximada. Alerta em caso de reutilização a partir de outro dispositivo/ASN — mesmo antes da vinculação entrar no ar.
• Bloqueie desvios na recuperação: Elimine SMS como método de recuperação para contas de alto risco. Migre para códigos de backup + fallback com chave de hardware e exija uma nova etapa de vinculação de dispositivo para gerar uma sessão pós‑recuperação.

Dia 31–60: Vincule tokens a dispositivos via DPoP

• Gere uma chave por dispositivo no cliente: Para SPAs, use WebCrypto para criar uma chave ECDSA P‑256 e persistir no IndexedDB. Para apps nativos, use o keychain do SO com armazenamento respaldado por hardware (Secure Enclave no iOS/macOS; StrongBox/TEE no Android).
• Adote OAuth DPoP para emissão de tokens: Quando o cliente solicitar um access/refresh token, inclua uma prova DPoP assinada pela chave do dispositivo. O servidor vincula o token emitido àquela chave pública. Veja RFC 9449.
• Exija DPoP em requisições de API: Para chamadas autenticadas com um access token, exija um cabeçalho DPoP provando a posse da chave vinculada. Rejeite tokens apresentados sem prova válida ou com método/URI incompatível.
• Rotacione e ateste: No refresh, exija uma nova prova. Considere atestação periódica de chave no mobile (Play Integrity / DeviceCheck) para camadas de maior risco. Não bloqueie a entrega por causa da disponibilidade de atestação — é um sinal adicional.
• Meça o overhead: A verificação ECDSA P‑256 normalmente adiciona ~0,3–0,9 ms de CPU por requisição em um core moderno. Faça orçamento de aproximadamente 1–2 KB de cabeçalho extra por chamada. Isso é ruído comparado ao custo de um ticket de suporte, quanto mais de um incidente.

Dia 61–90: Ative a vinculação nativa do navegador ao dispositivo e feche o ciclo

• Habilite sessões vinculadas ao dispositivo onde houver suporte: À medida que o recurso do Chrome for chegando, participe para seus domínios principais e mapeie a vinculação gerenciada pelo navegador para sua noção no servidor de uma chave de dispositivo. Mantenha DPoP como baseline entre navegadores.
• Reforce os caminhos de refresh: Todo caminho que retorna um novo token deve exigir prova de posse. Sem PoP, sem token. Isso inclui fluxos OAuth de device code, trocas PKCE e emissões de sessão pelo suporte ao cliente.
• Automação de incidentes: Diante de suspeita de roubo (token visto sem PoP ou com uma nova chave de dispositivo), revogue automaticamente aquela família de tokens, force uma nova vinculação de dispositivo e notifique o usuário. Adicione um clique “Não fui eu” que escale para revisão da conta inteira.
• Redesenho da recuperação: A recuperação cria uma sessão de baixo risco e curta duração que só pode ser elevada executando uma nova cerimônia WebAuthn ou produzindo a prova com a chave do dispositivo. Nada de salto direto para uma sessão de longa duração e privilégios completos.

Arquitetura de referência: como é o “bom”

1. Bootstrap da chave do dispositivo: No primeiro sign‑in (passkey/WebAuthn recomendado), o cliente gera um par de chaves de dispositivo de longa duração (WebCrypto ou keychain do SO). A chave pública e um ID de dispositivo aleatório são registrados com o seu serviço de autenticação.
2. Emissão de tokens com PoP: O cliente solicita tokens com uma prova DPoP. O serviço de autenticação vincula os tokens (access + refresh + cookie de sessão) à chave pública do dispositivo e os retorna. Cookies permanecem HttpOnly; a PoP vai em um cabeçalho.
3. Aplicação na API: Seu gateway de API valida o token e verifica a assinatura DPoP contra a chave pública vinculada, método e URL. Incompatibilidades, desalinhamento de relógio ou reutilização de um jti são rejeitados e sinalizados.
4. Disciplina de rotação: Access tokens expiram após 10–15 minutos. Refresh tokens são de uso único e rotacionam a cada troca. Cookies de sessão rotacionam a cada poucas horas ou mudança de privilégio. Todas as renovações exigem PoP.
5. Recuperação e step‑up: A recuperação cria uma sessão limitada, não um passe livre. Qualquer elevação (cobrança, exportação de dados, criação de chave de API) exige uma asserção WebAuthn ou PoP a partir da chave do dispositivo armazenada.
6. Telemetria: Armazene e analise “ID da chave de vinculação de dispositivo × IP AS number × plataforma”. Alerta para churn repentino de chaves de dispositivo para um usuário ou reutilização de uma chave de vinculação em muitas contas (automação maliciosa).

Trade‑offs e pegadinhas (reconheça agora)

• Nem todo navegador está pronto: Sessões vinculadas ao dispositivo chegarão de forma desigual. Por isso DPoP é o baseline entre navegadores. Mantenha fallbacks, mas não deixe que contornem a PoP silenciosamente.
• Proxies corporativos e gateways de API: Algumas middleboxes reescrevem cabeçalhos. Proteja cabeçalhos DPoP ponta a ponta (terminação TLS apenas na sua borda) e documente requisitos para clientes enterprise.
• Contas compartilhadas: Chega de compartilhamento. Implemente acesso delegado e chaves de API baseadas em função atreladas a cada usuário. Se for absolutamente necessário, dê suporte a separadas vinculações de dispositivo por operador e restrinja privilégios.
• Performance: PoP adiciona trabalho criptográfico. Amortize na borda, faça cache da introspecção de token e prefira ECDSA P‑256 a curvas mais pesadas. Na prática, a latência adicional é sub‑milissegundo em hardware comum.
• Ciclo de vida de chaves: Dispositivos são trocados. Forneça um fluxo limpo para “aposentar chave de dispositivo” e notifique sobre novas vinculações de dispositivo. Mantenha uma lista curta (5–10) de chaves de dispositivo ativas por usuário.
• Jurídico e privacidade: Vincular a uma chave de dispositivo não é fingerprinting. Você está armazenando uma chave pública, não um hash de canvas. Ainda assim, documente isso no seu aviso de privacidade e dê visibilidade e controle aos usuários.

Como isso se cruza com passkeys (e onde as equipes erram)

Passkeys provam que é a pessoa certa, em um dispositivo real, no momento do login. Depois disso, o risco migra para os tokens. Modos de falha comuns que vemos em auditorias:

• Passkey entra, bearer sai: Equipes atualizam o login para WebAuthn, mas ainda emitem um cookie bearer que qualquer máquina pode reutilizar. Você melhorou a porta da frente e deixou o cofre aberto.
• Pontos cegos na recuperação: SMS e links por email geram sessões não vinculadas. Use‑os para fazer o bootstrap de uma nova vinculação de dispositivo, não para contorná‑la.
• Refresh com vida longa: Refresh tokens de 30 dias sem PoP são um presente para infostealers. Rotacione a cada uso; expire rapidamente tokens não usados.

KPIs que o seu conselho vai aceitar

• Taxa de reutilização de sessão roubada: Mire em uma redução de 80%+ em até 90 dias após o rollout, medida por tokens apresentados sem PoP válida ou com uma nova vinculação de dispositivo.
• Tempo para revogar: Do primeiro uso suspeito do token até a revogação da família inteira em menos de 60 segundos.
• Cobertura: Percentual de sessões de usuários ativas com vinculação de dispositivo aplicada. Chegue a 70% no dia 60; 90% no dia 120.
• Carga de suporte: Menos tickets de ATO por milhão de MAU. Espere um pico de curto prazo ao fechar lacunas e, depois, uma queda constante.

Notas de implementação por plataforma

• Web (SPA/MPA): Gere chaves de dispositivo com WebCrypto; armazene no IndexedDB; assine DPoP com SubtleCrypto. Para MPA, você ainda pode manter um “service worker de chave do dispositivo” em segundo plano para assinar provas para POSTs privilegiados.
• Mobile: Chaves com suporte de hardware via Keychain (iOS) e Keystore (Android). Use atestação quando disponível. Vincule tokens a essas chaves; exija PoP no refresh e em chamadas de API sensíveis.
• Desktop (Electron/Tauri): Use APIs do keychain do SO. Impeça a exportação de chaves privadas. Considere mTLS para implantações enterprise internas.
• Servers e CLIs: Para automação, use credenciais de cliente OAuth de curta duração ou tokens de serviço com escopo e vinculados por PoP. Nunca coloque tokens bearer de longa duração em segredos de CI.

Estratégia de rollout: minimize quebras, maximize impacto

• Feature flag por público: Comece com contas de funcionários, depois um grupo de clientes de alto risco, e então o restante. Forneça uma UI de autoatendimento para gerenciamento de dispositivos antes de acionar o switch de forma ampla.
• Aplicação gradual: Modo apenas de log por uma semana, depois aplicação branda no refresh e, em seguida, aplicação rígida em todos os endpoints privilegiados.
• Comunique de verdade: Explique a mudança em linguagem simples: "Estamos vinculando sessões ao seu dispositivo para impedir roubo de tokens. Você verá um prompt único para registrar este dispositivo." Ofereça códigos de backup e etapas claras de recuperação.

Por que nearshore importa aqui

Isto não é um moonshot; é um projeto de engenharia disciplinado com critérios de aceitação claros. Um pod nearshore focado pode entregar ponta a ponta — mudanças no serviço de autenticação, aplicação no gateway, armazenamento de chaves em mobile/web, telemetria e playbooks do SOC — enquanto seu time central continua entregando produto. Espere 6–8 semanas de trabalho para um SaaS de porte médio (web + mobile), mais duas semanas de rollout em etapas e ajustes.

Em resumo

Passkeys tornaram phishing caro. Sessões vinculadas ao dispositivo tornam o roubo de tokens inviável. Combine a vinculação no nível do navegador conforme ela chegar com DPoP que você pode implantar hoje, e você tirará de cena a maior classe de ATO sem reconstruir toda a sua stack de autenticação. Se você puder entregar um projeto de segurança neste trimestre, que seja este.

Pontos‑chave

• Passkeys são necessárias, mas insuficientes; atacantes reutilizam tokens roubados para contorná‑las.
• As sessões vinculadas ao dispositivo do Chrome e o OAuth DPoP fecham a lacuna de replay ao exigir prova de posse.
• Entregue em 90 dias: encurte tokens, adicione telemetria, implemente DPoP e, depois, habilite a vinculação nativa do navegador conforme o rollout.
• Aplique PoP em todo refresh e chamada de API privilegiada; a recuperação deve fazer o bootstrap de uma nova vinculação de dispositivo, não contorná‑la.
• Espere overhead criptográfico sub‑milissegundo e uma queda mensurável em incidentes de ATO dentro de um trimestre.