Divulgação de afiliação - este artigo contém uma ligação de afiliado para um gestor de palavras-passe. Se subscrever através dela, recebemos uma comissão sem qualquer custo adicional para si. Isso não altera nada do que se segue: as conclusões abaixo vêm da Unit 42 da Palo Alto Networks e da imprensa técnica, e são atribuídas fonte a fonte.
Resposta curta: sim, as passkeys continuam seguras, e os investigadores que publicaram o ataque dizem-no com todas as letras. A 3 de agosto de 2026, a Unit 42 da Palo Alto Networks demonstrou que malware já em execução num PC Windows consegue sequestrar passkeys sincronizadas através do Google Password Manager. A frase deles é a que convém reter: "These attacks do not break the underlying cryptography." («estes ataques não quebram a criptografia subjacente»). O que quebraram foi a canalização à volta da passkey, não a passkey.
Essa distinção é a história toda, e a maioria dos títulos deixou-a cair.
O que foi realmente publicado
Arie Olshtein, investigador da Unit 42, publicou "Pass the Passkey: A Novel Attack Surface in Passwordless Authentication" a 3 de agosto de 2026. É um artigo técnico de investigação num blogue, não um estudo com revisão por pares, e vem de um fornecedor comercial de segurança, vale a pena dizê-lo claramente, porque é detalhado e credível, mas não é uma terceira parte neutra.
Descreve três técnicas, coletivamente designadas por ataques Pass-ta-key.
Pass-ta-key, o malware extrai do disco ou da memória a chave privada de identidade do dispositivo em formato encapsulado e, em seguida, invoca as APIs CNG do Windows (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) para que o TPM assine em seu nome. Assina o hash do handshake WebSocket e faz-se passar por uma instalação legítima do Chrome perante o autenticador na cloud da Google. Sem desbloqueio do dispositivo, sem interação do utilizador, sem escalada de privilégios. Repare na subtileza: a chave nunca sai do TPM, o TPM é simplesmente levado a trabalhar para o atacante.
Silver Pass-ta-key, o malware apaga passkey_enclave_state para forçar um novo registo do dispositivo, explora o estado transitório uv_key_pending e regista a sua própria chave de verificação de utilizador. A falha é precisa: o autenticador na cloud não valida a atestação das chaves UV recém-registadas, pelo que não consegue determinar se vieram de hardware seguro. Resultado: acesso reutilizável a partir de outra máquina, sem o dispositivo da vítima.
Golden Pass-ta-key, o pior dos três. O Security Domain Secret, uma chave-mestra de 32 bytes que protege todas as passkeys sincronizadas, é extraído da memória do processo do Chrome durante o novo registo. Com ele, um atacante desencripta os registos de credenciais guardados e leva consigo todas as passkeys sincronizadas na conta.
Os dois factos que tornam isto grave
A Google retirou o Security Domain Secret dos registos de diagnóstico do Chrome depois da divulgação. Mas a Unit 42 afirma que o segredo continua a ser enviado para o cliente e permanece acessível na memória do processo do Chrome, reconhecido, não corrigido.
E não existe forma de rodar ou revogar essa chave-mestra na implementação atual. As passkeys presentes e futuras continuam protegidas pelo mesmo segredo. É a parte mais dura deste caso, e aquela que não tem solução do lado do utilizador.
A condição que muda tudo
Todas estas técnicas pressupõem malware já em execução na máquina. Os investigadores dizem-no: "malware already existing on the victim's device during the initial stage." («malware já existente no dispositivo da vítima durante a fase inicial»).
Frank Dickson, da IDC, deu a formulação mais clara, na Computerworld: "This isn't passkeys getting hacked from across the internet. It's what [an attacker] does once they're already inside the house." («isto não são passkeys a serem pirateadas do outro lado da internet; é o que [um atacante] faz depois de já estar dentro de casa»).
Portanto, o perímetro é estreito e específico:
| Condição | Necessário |
|---|---|
| Sistema operativo | Windows |
| Navegador | Chrome |
| Armazenamento de credenciais | Google Password Manager (passkeys sincronizadas) |
| Hardware | Máquina com TPM |
| Pré-requisito | Malware já em execução localmente |
| Privilégios necessários | Nível de utilizador, sem elevação |
| Interação do utilizador | Nenhuma |
Não é preciso phishing, nem extensão maliciosa, nem sessão roubada, nem downgrade para outro fator. E nenhuma exploração remota: se a sua máquina estiver limpa, nada disto lhe chega.
O iCloud Keychain da Apple, o Windows Hello, o 1Password e o Bitwarden não foram testados. A Unit 42 observa que outros fornecedores usam um desenho de autenticador na cloud semelhante, o que é um aviso sobre a arquitetura, não uma conclusão de que sejam vulneráveis. Quem lhe disser que «todas as passkeys estão afetadas» está a ir além da investigação.
O que vale a pena mudar
Se for um particular. O único verdadeiro travão aqui é o pré-requisito: manter o malware fora da máquina. A recomendação da própria Unit 42 é investir em proteção do endpoint e tratar as passkeys como uma camada dentro de uma estratégia mais ampla, e não como uma linha de chegada. Para as contas de maior valor, email, banco, registador de domínios, uma chave de segurança física é a opção ligada ao dispositivo que esta investigação não toca, já que nada é sincronizado para um enclave na cloud. Isso é um compromisso, não um veredicto: ganha resistência a esta classe de ataque e perde a comodidade da sincronização entre dispositivos.
Se gere um serviço. A correção concreta é do lado do servidor e está identificada: exigir userVerification e validar efetivamente a flag UV na resposta de autenticação. Isto não é hipotético, o eBay estava a aceitar autenticações sem verificação de utilizador enquanto userVerification estava definido como required, e corrigiu-o após o relatório da Unit 42. O GitHub rejeitou corretamente o mesmo ataque. Uma implementação sólida aguenta; uma implementação desigual não. Como resumiu o analista Justin Greis na Computerworld: "The specification is sound, but the ecosystem implementing it is uneven." («a especificação é sólida, mas o ecossistema que a implementa é desigual»).
Para além disso, as medidas documentadas pelos investigadores e pelos analistas citados na Computerworld: validar a atestação da chave do dispositivo no momento do registo, monitorizar utilizações anómalas de passkeys, instalar EDR e deteção de ameaças de identidade (ITDR), definir uma política explícita sobre credenciais sincronizadas versus ligadas ao dispositivo e ensaiar os fluxos de recuperação, porque a recuperação e o novo registo são precisamente aquilo de que estes ataques abusam.
O que não se deve concluir
Várias afirmações que circulam esta semana não são suportadas pela investigação, e repeti-las seria errado:
- «As passkeys estão mortas / quebradas.» Contrariado por escrito pela Unit 42 e pela SecurityWeek.
- «A criptografia foi quebrada.» Não foi, explicitamente.
- «Voltem às palavras-passe.» Nenhuma fonte o recomenda, e reintroduziria o phishing e a reutilização de credenciais, exatamente os ataques que as passkeys eliminam.
- «É um CVE a ser ativamente explorado.» Não foi atribuído qualquer CVE à data de 3 de agosto, e não foi reportada qualquer exploração em ambiente real.
- «A Apple e a Microsoft também são afetadas.» Não testadas. Não é a mesma coisa.
O resumo honesto pertence à própria Unit 42: as passkeys são "a meaningful step forward in authentication security" («um passo em frente significativo na segurança da autenticação») porque eliminam os segredos partilhados e, com eles, classes inteiras de ataque. Esta investigação não inverte isso. Mostra que o ecossistema construído à volta das passkeys, registo, recuperação, sincronização na cloud, merece o mesmo escrutínio que a criptografia já recebeu.
A lição mais profunda, levantada por J. Wolfgang Goerlich na Computerworld, é a que vale a pena guardar: as passkeys sincronizadas reintroduziram um risco de portabilidade de credenciais que os autenticadores ligados ao dispositivo nunca tiveram. A comodidade entre dispositivos tem um preço, e esta é a primeira vez que o conseguimos ver com clareza.
Fontes
- Arie Olshtein, "Pass the Passkey: A Novel Attack Surface in Passwordless Authentication", Palo Alto Networks Unit 42, 3 de agosto de 2026, fonte primária, fornecedor comercial de segurança.
- BleepingComputer, 3 de agosto de 2026, primeira cobertura, assinala que não foi atribuído nenhum CVE.
- The Hacker News, 3 de agosto de 2026, «os ataques visam o código à volta da passkey».
- SecurityWeek, 5 de agosto de 2026, « That does not mean passkeys are broken » («isso não significa que as passkeys estejam quebradas»).
- Computerworld, Evan Schuman, 5 de agosto de 2026, comentários de analistas (Dickson, Greis, Goerlich, Levine, Finkelstein).
- Biometric Update, 7 de agosto de 2026, posição estabelecida da FIDO Alliance, nenhuma exploração em ambiente real.
Dados e declarações verificados a 9 de agosto de 2026. A Google não tinha feito qualquer declaração pública sobre o fundo da questão nessa data; é o ponto com maior probabilidade de ter mudado entretanto.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Um gestor com 2FA e passkeys integrados → NordPassGuarde TOTP e passkeys · XChaCha20 · plano gratuito→Perguntas frequentes
As passkeys continuam seguras depois da investigação Pass-ta-key?
Sim, e são os próprios investigadores que o dizem. A Unit 42 da Palo Alto Networks afirma sem rodeios que « These attacks do not break the underlying cryptography » («estes ataques não quebram a criptografia subjacente»). A SecurityWeek acrescenta que « That does not mean passkeys are broken » («isso não significa que as passkeys estejam quebradas») nem que as pessoas devam deixar de as usar. O que a investigação demonstra é que malware que já esteja em execução num PC Windows consegue abusar da maquinaria em torno da passkey, a sincronização na cloud da Google, e não da passkey em si. As passkeys continuam a ser uma melhoria real face às palavras-passe, porque eliminam o segredo partilhado de que dependem o phishing e o credential stuffing.
O que é que os ataques Pass-ta-key exploram exatamente?
Três técnicas distintas, todas publicadas pela Unit 42 a 3 de agosto de 2026. O Pass-ta-key extrai a chave de identidade do dispositivo em formato encapsulado e usa as APIs CNG do Windows para fazer com que o TPM assine em nome do atacante, fazendo-se passar por uma instalação legítima do Chrome perante o autenticador na cloud da Google. O Silver Pass-ta-key força um novo registo do dispositivo e regista a própria chave de verificação de utilizador do atacante, porque o autenticador na cloud não valida a atestação das chaves UV recém-registadas. O Golden Pass-ta-key extrai o Security Domain Secret, uma chave-mestra de 32 bytes, da memória do processo do Chrome, com ela, é possível desencriptar todas as passkeys sincronizadas na conta.
Sou afetado?
Apenas sob um conjunto específico de condições, e todas têm de se verificar ao mesmo tempo: Windows, Chrome, passkeys sincronizadas através do Google Password Manager, uma máquina com TPM e, acima de tudo, malware já em execução nessa máquina. Não existe exploração remota: os investigadores afirmam que o ataque exige « malware already existing on the victim's device » («malware já existente no dispositivo da vítima»). O analista da IDC Frank Dickson resumiu-o com clareza na Computerworld, isto não são passkeys a serem pirateadas do outro lado da internet, é aquilo que um atacante faz depois de já estar dentro de casa.
A Apple, a Microsoft ou os gestores de palavras-passe de terceiros são afetados?
Não está estabelecido, e seria errado afirmar o contrário. A Unit 42 testou o Google Password Manager no Chrome em Windows. O iCloud Keychain, o Windows Hello, o 1Password, o Bitwarden e outros não foram testados. A Unit 42 observa, isso sim, que outros fornecedores usam um modelo de autenticador na cloud semelhante, o que é um aviso sobre o desenho da arquitetura e não uma conclusão de vulnerabilidade. Trate-os como não testados, nem como seguros nem como vulneráveis.
A Google já corrigiu isto?
Em parte, e é importante ser preciso. A Google retirou o Security Domain Secret dos registos de diagnóstico do Chrome depois da divulgação. Mas a Unit 42 nota que o segredo continua a ser enviado para o cliente e permanece acessível na memória do processo do Chrome, e essa questão foi reconhecida, não resolvida. Pior: a implementação atual não oferece qualquer forma de rodar ou revogar essa chave-mestra, pelo que as passkeys presentes e futuras continuam protegidas pela mesma. À data de publicação, a Google não tinha feito qualquer declaração pública sobre o fundo da questão, e a divulgação não estabelece que os três caminhos de ataque estejam fechados.
Devo deixar de usar passkeys sincronizadas e voltar às palavras-passe?
Nenhuma fonte o recomenda, e nós também não. Voltar às palavras-passe é reintroduzir exatamente os ataques que as passkeys eliminam, phishing, reutilização, credential stuffing, em troca de proteção contra um ataque que exige que a sua máquina já esteja comprometida. A distinção mais útil, levantada por J. Wolfgang Goerlich na Computerworld, é que as passkeys sincronizadas reintroduziram um risco de portabilidade de credenciais que os autenticadores ligados ao dispositivo não tinham. Para as contas de maior valor, uma chave de segurança física é a opção ligada ao dispositivo.
O que deve uma empresa fazer quanto a isto?
A medida concreta apontada pelos investigadores e pelos analistas é do lado do servidor: exigir userVerification e validar efetivamente a flag UV na resposta de autenticação. Essa lacuna não é teórica, o eBay aceitava autenticações sem verificação de utilizador mesmo com userVerification definido como obrigatório, e corrigiu-o após o relatório da Unit 42. O GitHub rejeitou corretamente o mesmo ataque, o que mostra que uma implementação correta aguenta. Além disso: validar a atestação da chave do dispositivo, monitorizar utilizações anómalas de passkeys, instalar deteção ao nível do endpoint e definir uma política explícita sobre credenciais sincronizadas versus ligadas ao dispositivo.
Este ataque foi usado contra pessoas reais?
Não foi reportada qualquer exploração em ambiente real. A Biometric Update assinalou a 7 de agosto de 2026 que se trata de investigação demonstrativa, e que não tinha sido atribuído nenhum CVE à data de 3 de agosto. Isso importa para a forma como deve reagir: é uma razão para rever como as suas contas se recuperam e se voltam a registar, não uma razão para entrar em pânico.
