A promessa das passkeys é ambiciosa: eliminar senhas, reduzir o phishing e tornar o roubo de credenciais muito mais difícil. Mas pesquisas recentes mostram que ataques a passkeys continuam possíveis quando a implementação ao redor do padrão FIDO2/WebAuthn apresenta falhas. O ponto mais importante é que os pesquisadores não quebraram a criptografia usada pelas passkeys. Eles encontraram maneiras de abusar do Windows, do navegador, do armazenamento de credenciais e da validação feita pelos serviços.
Essa distinção é fundamental. Uma passkey corretamente implementada continua sendo uma das formas mais resistentes de autenticação contra phishing. O problema aparece quando uma chave privada, uma assinatura já produzida ou informações necessárias para autenticação acabam expostas em locais onde não deveriam estar. Nesse cenário, o atacante não precisa descobrir a matemática por trás da criptografia: basta explorar a forma como o sistema operacional ou o serviço administra aquela credencial.
As pesquisas da SpecterOps, da Unit 42, da Palo Alto Networks e de pesquisadores independentes mostram justamente esse cenário. De um lado, existe o Pass-the-Passkey, envolvendo Windows e Microsoft Entra ID. Do outro, estão os ataques Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key, que exploram a implementação do Google Password Manager no Chrome.
O problema não é a criptografia, são as implementações por trás das passkeys
O funcionamento básico de uma passkey é relativamente elegante. Durante o registro, o dispositivo cria um par de chaves criptográficas. A chave privada permanece protegida no dispositivo ou no mecanismo de armazenamento escolhido, enquanto a chave pública é registrada no serviço.
Durante o login, o servidor envia um desafio. O autenticador assina esse desafio com a chave privada e devolve a assinatura. O servidor verifica a assinatura usando a chave pública.
Em condições normais, isso significa que não existe uma senha secreta para o atacante roubar ou reutilizar.
O problema é que o processo real envolve muito mais componentes: navegador, sistema operacional, TPM, armazenamento de credenciais, sincronização em nuvem, APIs, serviços de identidade, registros de eventos e validação do servidor.
É justamente nessa camada que surgem os ataques a passkeys.
A falha de registro do Windows e o ataque Pass-the-Passkey
O pesquisador Michael Grafnetter, da SpecterOps, apresentou em agosto de 2026 a pesquisa Pass-the-Passkey Family of Attacks. O trabalho identificou falhas em implementações reais que permitiam reproduzir técnicas conceitualmente semelhantes ao Pass-the-Hash e ao NTLM Relay.
Um dos problemas recebeu o identificador CVE-2026-34348. Segundo o registro do NVD, a vulnerabilidade está relacionada a uma falha de proteção no Windows Event Logging Service, permitindo que um atacante autorizado obtenha informações por meio da rede. A vulnerabilidade foi corrigida pela Microsoft em julho.
O detalhe preocupante é que o problema não estava na capacidade matemática da chave FIDO2 de resistir a ataques. Em determinadas circunstâncias, informações relacionadas às credenciais podiam aparecer em mecanismos de registro do Windows.
Isso muda completamente o modelo de ameaça.
Se uma assinatura ou material relacionado à autenticação é armazenado em texto recuperável, o atacante pode tentar reutilizar o artefato, em vez de quebrar a chave privada original.
A pesquisa também mostrou uma segunda parte importante: a validação realizada pelo serviço de identidade. Quando o servidor não impede adequadamente a reutilização de determinados dados de autenticação, uma informação obtida anteriormente pode ganhar uma segunda vida.
É daí que surge o conceito Pass-the-Passkey: em vez de roubar uma senha e reutilizá-la, o atacante tenta roubar ou reproduzir elementos do processo de autenticação baseado em passkeys.
A própria SpecterOps destaca que a categoria pode permitir impersonação de usuários, bypass de MFA resistente a phishing e evasão de algumas soluções de detecção, dependendo da combinação de falhas explorada.
Extração de chaves privadas no Google Password Manager
O segundo conjunto de descobertas veio da Unit 42, que analisou o autenticador em nuvem usado pelo Google Password Manager no Chrome.
Os pesquisadores identificaram três caminhos de ataque chamados Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key. Todos possuem uma característica importante: o dispositivo da vítima precisa estar previamente comprometido por malware.
No primeiro cenário, chamado Pass-ta-key, o malware pode abusar da identidade do dispositivo e solicitar operações de autenticação sem necessariamente provocar a tradicional confirmação do usuário.
Isso não significa que qualquer pessoa na internet possa simplesmente entrar em uma conta protegida por passkey. O cenário pressupõe comprometimento local da máquina.
O Silver Pass-ta-key explora o processo de novo registro do dispositivo. Sob determinadas condições, o navegador pode entrar em um estado no qual a chave utilizada para verificação do usuário ainda não foi criada. A pesquisa mostrou que esse intervalo pode ser abusado para introduzir uma chave controlada pelo atacante.
Já o Golden Pass-ta-key é o cenário mais grave.
A Unit 42 demonstrou que o malware poderia tentar obter o Security Domain Secret (SDS) enquanto o Chrome o utiliza em memória. Esse segredo funciona como uma peça central na proteção das passkeys sincronizadas pelo Google Password Manager.
Se esse segredo for obtido, o atacante pode tentar recuperar as chaves privadas sincronizadas, transformando um comprometimento local em um problema potencialmente muito maior.
A descoberta também reforça uma segunda responsabilidade: o site que recebe a autenticação precisa validar corretamente a resposta WebAuthn. A Unit 42 encontrou diferenças entre serviços, com casos em que a validação foi corretamente aplicada e outros nos quais uma assinatura inadequadamente verificada foi aceita.
Bypass de MFA e uso indevido do Windows Hello
As passkeys não devem ser analisadas isoladamente do Windows Hello e do Windows Hello for Business.
Pesquisas de Dirk-jan Mollema e outros especialistas já demonstraram que credenciais do Windows Hello podem ser abusadas depois que um invasor conquista controle suficiente sobre uma sessão Windows. O trabalho apresentado em conferências de segurança explorou a proteção das chaves, provisionamento, autenticação e possibilidades de movimento lateral em ambientes Microsoft Entra ID.
O aspecto particularmente interessante é que uma chave protegida por TPM não necessariamente impede todo tipo de abuso local.
O TPM pode impedir que um atacante simplesmente copie a chave privada e a leve para outro computador. Porém, se um malware já estiver executando dentro da sessão legítima, ele pode tentar solicitar operações criptográficas ao sistema usando a identidade e os privilégios disponíveis naquele ambiente.
Nesse caso, não é necessário quebrar o TPM.
A ameaça passa a ser o próprio endpoint comprometido.
Essa diferença é essencial para administradores: hardware-bound não significa automaticamente malware-proof.
Uma máquina Windows infectada continua sendo uma superfície crítica de ataque mesmo quando todas as credenciais modernas estão vinculadas a hardware.
Chaves sincronizadas versus chaves vinculadas ao hardware: qual é a diferença no risco?
Nem todas as passkeys possuem o mesmo modelo de segurança.
As passkeys sincronizadas priorizam conveniência. Elas podem ser disponibilizadas em diferentes dispositivos por meio de mecanismos de sincronização do provedor. A Microsoft, por exemplo, diferencia credenciais sincronizadas de chaves de segurança FIDO2 em suas orientações para ambientes corporativos.
Essa abordagem melhora significativamente a experiência do usuário. A perda de um smartphone ou notebook não significa necessariamente perder todas as credenciais.
Por outro lado, a sincronização cria uma camada adicional de infraestrutura.
Existe um serviço de nuvem, existe um mecanismo de recuperação e existe material criptográfico necessário para disponibilizar a credencial em outro dispositivo.
As chaves FIDO2 físicas, por sua vez, oferecem um modelo diferente. A chave privada permanece dentro do dispositivo de hardware e as operações criptográficas são realizadas pelo próprio autenticador.
Para ambientes altamente privilegiados, isso pode reduzir a superfície de ataque.
A própria Microsoft recomenda chaves FIDO2 de segurança para administradores e usuários altamente regulados, enquanto passkeys sincronizadas aparecem como opção recomendada para outros perfis.
Na prática, empresas precisam avaliar o risco de acordo com a função.
Administradores de domínio, equipes de infraestrutura, contas de emergência e identidades com privilégios elevados merecem controles mais rígidos. Também é importante limitar métodos alternativos de autenticação, monitorar alterações de credenciais e manter Windows, navegadores e componentes de identidade atualizados.
Outro ponto fundamental é o monitoramento.
Se uma organização adota passkeys, seu plano de resposta a incidentes precisa responder a uma pergunta simples: o que acontece quando um endpoint que contém ou utiliza passkeys é comprometido?
Sem uma resposta clara para revogação, re-registro e recuperação, a migração para passwordless fica incompleta.
Conclusão e próximos passos para segurança de endpoints
Os recentes ataques a passkeys não significam que FIDO2 ou WebAuthn fracassaram.
Na realidade, as pesquisas reforçam uma lição conhecida em segurança: um protocolo criptograficamente robusto pode ser enfraquecido por uma implementação insegura.
A criptografia das passkeys continua sendo uma barreira importante contra phishing, reutilização de senhas e roubo tradicional de credenciais. O problema aparece quando o ecossistema ao redor da chave expõe informações sensíveis, aceita estados inválidos, permite re-registros inadequados ou não valida corretamente uma assinatura.
Para administradores, a resposta deve passar por Zero Trust, atualização contínua, EDR, controle de privilégios, proteção de navegadores, auditoria de registros, políticas rigorosas de identidade e uso de hardware autenticador para contas críticas.
Também é necessário abandonar a ideia de que “passwordless” significa automaticamente “sem risco”.
O cenário real é mais interessante: passkeys eliminam várias classes de ataques, mas criam uma nova responsabilidade para quem administra a infraestrutura. É preciso proteger não apenas a chave, mas todo o caminho percorrido por ela.
O futuro da autenticação provavelmente será cada vez menos dependente de senhas. Porém, a transição para passkeys precisa ser acompanhada por testes de implementação, monitoramento e planos de recuperação capazes de lidar com o comprometimento de endpoints.
A pergunta para as empresas deixa de ser apenas “quando vamos eliminar as senhas?” e passa a ser: “como vamos proteger nossas passkeys quando o dispositivo, navegador ou serviço de identidade for comprometido?”
Esse é o verdadeiro desafio da segurança passwordless.