Não, a nova pesquisa da Unit 42 não mostrou que a criptografia das passkeys foi quebrada nem que elas deixaram de ser resistentes a phishing. O trabalho revelou três formas de abusar da implementação de passkeys sincronizadas pelo Google Password Manager quando malware já está executando no computador da vítima. O estudo se concentrou no Chrome para Windows, em dispositivos com Trusted Platform Module (TPM).
Essa diferença é importante. Passkeys continuam usando criptografia de chave pública e são vinculadas ao site ou aplicativo para o qual foram criadas. Essa vinculação impede o uso normal da credencial em um site de phishing que imita o endereço legítimo. Google e FIDO Alliance continuam descrevendo essa propriedade como resistência a phishing.
O que a pesquisa questiona é outra camada: o que acontece quando o próprio dispositivo que armazena, sincroniza ou autoriza o uso da passkey já está comprometido.
O que a Unit 42 encontrou
A Unit 42 apresentou três classes de ataque, batizadas de Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key. Em todos os casos demonstrados, o ponto de partida é malware presente no computador da vítima; os pesquisadores afirmam explicitamente que os ataques não quebram a criptografia subjacente das passkeys.
- Pass-ta-key: malware sem privilégios administrativos pode abusar da identidade de dispositivo usada pelo Chrome para solicitar ao autenticador em nuvem do Google uma resposta criptograficamente válida. O ataque não exige que a vítima desbloqueie o computador ou confirme a operação naquele momento. Ele tende a falhar quando o serviço exige e verifica corretamente o indicador de que houve autenticação local do usuário.
- Silver Pass-ta-key: a pesquisa mostrou uma forma de manipular o processo de novo registro do dispositivo e cadastrar uma chave de verificação controlada pelo atacante. Segundo a Unit 42, o autenticador em nuvem não verificava adequadamente se essa nova chave vinha de hardware confiável. Depois desse registro, o atacante poderia produzir autenticações tratadas como verificadas mesmo a partir de outro sistema.
- Golden Pass-ta-key: o cenário de maior impacto envolve o Security Domain Secret, ou SDS, segredo mestre usado para proteger as passkeys sincronizadas da conta. A Unit 42 encontrou inicialmente esse segredo em texto legível nos logs internos do Chrome. O Google retirou o SDS desses logs após o relato, mas os pesquisadores afirmam que ele ainda passa temporariamente pela memória do processo do Chrome durante determinadas operações de registro ou recuperação. Malware presente no endpoint poderia, nesse cenário, tentar extrair o segredo e usá-lo para recuperar as chaves privadas das passkeys sincronizadas.
O último cenário também expõe um problema de persistência apontado pelos pesquisadores: segundo a Unit 42, a implementação analisada não oferece um mecanismo para rotacionar ou revogar o SDS, que protege tanto credenciais existentes como novas passkeys sincronizadas posteriormente.
Por que isso não equivale a “quebrar passkeys”
A resistência a phishing resolve um problema específico. Em uma autenticação WebAuthn normal, a passkey está vinculada à identidade do serviço, e navegador e sistema operacional impedem que uma página fraudulenta simplesmente peça a mesma credencial e a reutilize. O servidor também guarda a chave pública, e não um segredo equivalente à chave privada do usuário.
Os ataques da Unit 42 começam depois de uma barreira diferente já ter sido ultrapassada: o atacante conseguiu executar malware no computador da vítima.
Isso não torna o resultado irrelevante. Pelo contrário, ele mostra que substituir senhas por passkeys não elimina a necessidade de proteger endpoints, navegadores, processos de recuperação e mecanismos de sincronização. Mas é diferente de descobrir uma técnica remota capaz de obter uma passkey por phishing ou de derivar sua chave privada a partir da chave pública armazenada pelo site.
A própria Unit 42 conclui que passkeys continuam sendo um avanço significativo em relação às senhas, porque eliminam segredos compartilhados e reduzem classes inteiras de ataques. O trabalho chama atenção para as novas superfícies criadas pelas implementações sincronizadas e pelos sistemas que decidem quando confiar em um dispositivo.
O primeiro ataque também mostrou que o site importa
Um detalhe do experimento ajuda a entender por que passkey não é apenas uma questão do navegador ou do gerenciador de credenciais.
Na primeira técnica, a resposta produzida pelo autenticador contém um indicador chamado User Verified, ou UV, que informa se ocorreu a verificação local exigida, como PIN ou biometria. A Unit 42 tentou o ataque contra o GitHub e não conseguiu autenticar porque o serviço verificou esse indicador. No eBay, porém, os pesquisadores conseguiram concluir o login durante os testes porque a validação não estava sendo aplicada corretamente. O eBay corrigiu o problema após receber o relatório.
Isso mostra que a segurança final também depende de quem recebe a autenticação. A recomendação da Unit 42 para serviços que usam passkeys é exigir a verificação do usuário quando apropriado e validar efetivamente o indicador UV recebido, em vez de apenas solicitar a verificação no início do fluxo.
O que muda para quem já usa passkeys
Para a maioria das pessoas, a pesquisa não é um motivo para voltar às senhas. Senhas continuam sujeitas a phishing, reutilização, vazamentos e roubo de credenciais, enquanto passkeys foram projetadas justamente para eliminar vários desses caminhos. A documentação atual do Google continua classificando as passkeys como uma alternativa mais segura contra phishing e recomenda não criá-las em dispositivos compartilhados.
O resultado reforça, porém, que a segurança da conta não termina no método de login. Sistema operacional e navegador precisam permanecer atualizados, e sinais de comprometimento por malware devem ser tratados como um problema de segurança da máquina inteira, não apenas da senha ou da passkey.
A Unit 42 também recomenda atenção a solicitações inesperadas ou repetidas do PIN de recuperação do Google Password Manager. Esse tipo de solicitação costuma estar associado a registro ou recuperação do dispositivo, e a pesquisa mostrou que forçar esses fluxos fazia parte dos cenários Silver e Golden.
Quem suspeita que um computador esteja comprometido deve priorizar a contenção e limpeza do dispositivo e revisar acessos, sessões, dispositivos e credenciais associados à conta a partir de um ambiente confiável. O Google permite consultar e remover passkeys e dispositivos vinculados à Conta do Google.
No cenário específico de possível exposição do SDS descrito pela Unit 42, a situação exige cautela adicional: os pesquisadores afirmam que a implementação analisada não disponibiliza rotação ou revogação desse segredo mestre. Portanto, não é prudente assumir que apenas trocar uma senha resolveria uma exposição dessa natureza.
As falhas já foram corrigidas?
Há correções parciais confirmadas nas fontes consultadas. O eBay corrigiu a validação do indicador de verificação do usuário depois de receber o relatório. O Google também removeu o Security Domain Secret dos logs internos do Chrome após a divulgação responsável do problema.
A Unit 42, entretanto, afirma em seu artigo que o SDS ainda é enviado ao cliente e pode permanecer temporariamente acessível na memória do processo do Chrome. Em 3 de agosto de 2026, o BleepingComputer informou que havia procurado o Google para saber se todos os cenários estavam resolvidos, mas não havia recebido resposta até a publicação.
Até 9 de agosto de 2026, as fontes públicas consultadas para este artigo não permitem afirmar que todas as condições descritas pela pesquisa tenham sido eliminadas. Os relatórios públicos do Google vinculados pela Unit 42 também não expõem seus detalhes sem autenticação, o que limita uma confirmação independente do status de cada correção.
Passkeys continuam valendo a pena?
O resultado da pesquisa aponta mais para uma mudança no modelo de ameaça do que para o fracasso das passkeys.
Enquanto senhas dão aos atacantes um segredo que pode ser roubado por phishing, reutilizado ou testado em outros serviços, passkeys eliminam esse segredo compartilhado e vinculam a autenticação ao serviço legítimo.
O novo alvo passa a ser o ambiente ao redor da credencial: dispositivo, navegador, gerenciador de passkeys, sincronização, recuperação e validação realizada pelo serviço.
A leitura prática, portanto, não é “passkeys foram quebradas”. É: passkeys dificultam ataques tradicionais, mas não tornam seguro um computador que já está sob controle de malware. A pesquisa da Unit 42 mostra onde implementações sincronizadas ainda precisam ser endurecidas para que as garantias do protocolo sobrevivam também a esse cenário.
