As passkeys vêm sendo apresentadas como uma das principais alternativas às senhas tradicionais. Em vez de depender de uma combinação que pode ser descoberta, reutilizada ou capturada em ataques de phishing, esse método utiliza chaves criptográficas associadas ao dispositivo e mecanismos como biometria, PIN ou bloqueio de tela. Apesar do avanço em segurança, uma nova pesquisa mostra que a tecnologia não elimina todos os riscos relacionados ao processo de autenticação. Pesquisadores da Unit 42, divisão de inteligência da Palo Alto Networks, identificaram diferentes técnicas capazes de explorar o ecossistema de passkeys sincronizadas pelo Google Password Manager em dispositivos previamente comprometidos. O estudo, publicado em agosto de 2026, demonstra que um malware com acesso suficiente à máquina pode interferir em etapas importantes do gerenciamento dessas credenciais.
O que são passkeys?
As passkeys foram desenvolvidas para substituir senhas utilizando criptografia de chave pública.
Quando uma passkey é criada, duas partes estão envolvidas: uma chave privada, protegida no dispositivo ou no gerenciador de credenciais, e uma chave pública, armazenada pelo serviço em que o usuário possui uma conta.
Durante a autenticação, o serviço envia um desafio que precisa ser validado utilizando a chave privada. Como essa chave não é compartilhada com o site durante o login, o método oferece maior resistência contra roubo de credenciais e páginas falsas de phishing.
O próprio Google apresenta as passkeys como uma alternativa mais segura às senhas, permitindo autenticação por impressão digital, reconhecimento facial ou bloqueio de tela.
Isso, porém, não significa que todo o ambiente ao redor das passkeys seja imune a ataques.
Pesquisadores encontraram novos caminhos de ataque
A pesquisa, conduzida por Arie Olshtein e pesquisadores da Unit 42, batizou essa nova classe de ataques de Pass-ta-key, em referência ao conceito de “passar a chave” entre dispositivos e serviços.
Os pesquisadores demonstraram três técnicas diferentes contra passkeys sincronizadas pelo Google Password Manager: Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key.
No ataque Pass-ta-key, um malware executado no dispositivo da vítima pode utilizar a identidade criptográfica já associada ao computador para solicitar uma autenticação válida ao Google Cloud Authenticator. O processo pode ocorrer sem interação do usuário, sem desbloqueio do dispositivo e sem necessidade de privilégios administrativos.
O Silver Pass-ta-key vai além. Nesse cenário, o atacante consegue substituir a chave utilizada para comprovar a verificação do usuário por outra chave sob seu controle. Depois disso, ele pode gerar autenticações consideradas válidas mesmo em serviços que exigem confirmação por PIN ou biometria, sem precisar manter acesso ativo ao computador da vítima.
Já o Golden Pass-ta-key representa o cenário mais crítico. Ele permite obter o segredo utilizado para proteger as passkeys sincronizadas e, a partir dele, recuperar as próprias chaves privadas armazenadas na conta. Isso transforma as passkeys em credenciais potencialmente reutilizáveis fora do dispositivo original.
É importante destacar que o estudo não descreve um problema genérico em qualquer implementação de passkeys. Os testes da Unit 42 foram realizados especificamente com o Google Password Manager no Chrome para Windows, em computadores equipados com TPM (Trusted Platform Module). Todos os ataques apresentados também partem de uma condição inicial: o dispositivo da vítima já precisa estar comprometido por malware.
Isso significa que as passkeys foram quebradas?
Um dos pontos mais relevantes da pesquisa está no funcionamento interno do Google Password Manager.
As passkeys sincronizadas são protegidas por uma chave mestra chamada Security Domain Secret (SDS). Esse segredo possui 32 bytes e é utilizado para proteger as chaves privadas associadas às passkeys armazenadas na conta Google.
Em condições normais, o SDS deveria permanecer protegido pela infraestrutura do Google Cloud Authenticator. Entretanto, os pesquisadores descobriram que, durante determinados processos de registro e recuperação do dispositivo, esse segredo chega ao Chrome em uma forma acessível.
Inicialmente, a Unit 42 encontrou o SDS sendo exibido diretamente nos logs internos do Chrome. Após o reporte, o Google removeu essa exposição dos registros.
O problema, porém, não desapareceu completamente.
Segundo os pesquisadores, durante o processo de reentrada de um dispositivo no ecossistema de passkeys, o SDS ainda é enviado ao cliente e permanece temporariamente em texto puro na memória do processo do Chrome.
No ataque Golden Pass-ta-key, um malware pode forçar uma nova etapa de registro, monitorar esse processo e extrair o conteúdo da memória do navegador no momento em que o SDS está disponível.
Com esse segredo, o invasor consegue descriptografar os registros de passkeys armazenados localmente pelo Chrome e recuperar suas chaves privadas.
O impacto é significativo porque o SDS não protege apenas uma única credencial. Ele está relacionado às passkeys sincronizadas da conta, permitindo que um comprometimento desse segredo tenha consequências muito mais amplas do que o roubo de uma senha individual.
O problema está além da credencial
A descoberta reforça um princípio importante da segurança da informação: nenhum mecanismo de autenticação funciona isoladamente.
Uma passkey pode utilizar criptografia robusta e ainda depender da segurança do navegador, do sistema operacional, do gerenciador de credenciais e do próprio dispositivo em que está armazenada.
A Unit 42 já havia analisado anteriormente a infraestrutura utilizada pelo Google para permitir que passkeys armazenadas no Google Password Manager funcionem em diferentes plataformas, incluindo Windows, macOS, Linux e ChromeOS.
Essa arquitetura permite oferecer uma experiência transparente para o usuário, mas também cria componentes adicionais que precisam ser protegidos.
Por isso, a adoção de autenticação sem senha não substitui controles básicos de segurança do endpoint.
Malware continua sendo uma ameaça
O cenário apresentado pelos pesquisadores mostra por que proteger o dispositivo continua sendo essencial mesmo após a adoção de métodos modernos de autenticação.
Caso um invasor obtenha execução de código no computador da vítima e consiga ampliar seu nível de acesso, ele pode tentar manipular aplicações, interceptar informações locais ou utilizar sessões já autenticadas.
Em ambientes corporativos, o risco torna ainda mais importante a combinação de diferentes camadas de proteção.
Manter sistemas e navegadores atualizados, limitar privilégios administrativos, controlar softwares instalados, monitorar comportamentos suspeitos e reduzir a exposição a malware continuam sendo medidas fundamentais.
A passkey deve ser entendida como uma evolução importante da autenticação, e não como substituta de toda a estratégia de segurança de um dispositivo.
Passkeys ainda são mais seguras que senhas?
A Unit 42 também testou como serviços reais reagiriam ao primeiro ataque Pass-ta-key.
O ponto central está em um campo chamado User Verified (UV). Durante uma autenticação WebAuthn, esse indicador informa ao serviço se houve uma verificação adicional do usuário, como PIN, biometria ou desbloqueio do dispositivo.
No ataque básico Pass-ta-key, a resposta criptográfica gerada continua sendo válida, mas o indicador UV permanece desativado.
Ao testar o ataque contra uma conta protegida por passkey no GitHub, os pesquisadores não conseguiram concluir o login. O serviço verificou corretamente que a autenticação não possuía confirmação de usuário e rejeitou a tentativa.
No eBay, porém, o resultado foi diferente.
Embora o site configurasse a autenticação para exigir verificação do usuário, durante os testes ele não validava corretamente o indicador UV retornado pela autenticação. Com isso, a Unit 42 conseguiu realizar um login com sucesso sem interação adicional da vítima.
A falha foi comunicada ao eBay e, segundo os pesquisadores, posteriormente corrigida.
O exemplo mostra que a segurança das passkeys não depende apenas do navegador ou do gerenciador de credenciais. O serviço que recebe a autenticação também precisa validar corretamente todas as propriedades da resposta WebAuthn.
Segurança precisa continuar em camadas
Para aplicações que utilizam WebAuthn, a pesquisa deixa uma recomendação prática importante: não basta solicitar verificação do usuário; é necessário confirmar que ela realmente ocorreu.
Ao iniciar uma autenticação, o serviço deve configurar userVerification como required quando a verificação adicional fizer parte dos requisitos de segurança.
Além disso, o servidor precisa validar o indicador UV (User Verified) presente nos dados retornados pelo autenticador.
Essa segunda etapa é fundamental.
O caso observado no eBay demonstrou que simplesmente solicitar userVerification: required não impede o ataque caso a aplicação aceite posteriormente uma resposta em que o indicador UV não esteja marcado.
Em outras palavras, a aplicação deve verificar tanto a validade criptográfica da autenticação quanto se o usuário efetivamente realizou a etapa de verificação esperada.
Para sistemas que protegem dados sensíveis, operações financeiras ou acessos privilegiados, essa validação deve fazer parte da implementação padrão do WebAuthn.
