Investigadores da Unit 42, a equipa de investigação de ameaças da Palo Alto Networks, revelaram três novas técnicas de ataque contra as passkeys (chaves de acesso) sincronizadas através do Google Password Manager no navegador Chrome em sistemas Windows. As técnicas, coletivamente designadas “Pass-ta-key”, não quebram a segurança criptográfica das passkeys, mas exploram fragilidades nos mecanismos de confiança, recuperação e sincronização entre o Google Password Manager, o Chrome e o autenticador na nuvem da Google. Um pormenor essencial: todos os ataques exigem que o malware já esteja em execução no PC Windows da vítima, visam as passkeys sincronizadas no Chrome em dispositivos com um Trusted Platform Module (TPM) e não constituem uma exploração remota contra contas Google.
Resposta rápida: Os ataques “Pass-ta-key” só funcionam se o computador Windows já estiver comprometido por malware — não são exploráveis apenas por visitar um site. As passkeys continuam a ser mais seguras do que as palavras-passe contra phishing. A ação prática é manter o endpoint limpo (EDR/antivírus atualizado, cuidado com downloads e anexos) e, no caso de suspeita de infeção, deixar de usar o PC para iniciar sessões e reforçar a proteção da conta Google.
O que são realmente as passkeys e porque continuam a valer a pena
As passkeys são um método de autenticação sem palavra-passe. Baseiam-se em chaves criptográficas guardadas no dispositivo do utilizador para iniciar sessão em contas online e são consideradas mais seguras do que as palavras-passe porque não podem ser adivinhadas, reutilizadas ou facilmente roubadas por phishing, permitindo ainda autenticar com um PIN ou biometria, como impressão digital ou reconhecimento facial.
É importante enquadrar corretamente esta investigação. Segundo os investigadores, os ataques demonstram que, embora as passkeys ajudem a combater o phishing, não oferecem proteção contra um sistema que já foi comprometido. Por outras palavras: o problema não está na matemática das passkeys, mas sim no código à sua volta e no facto de uma passkey sincronizada herdar a segurança do dispositivo mais fraco onde é sincronizada.
Ataque 1 — Pass-ta-key: fazer-se passar por um dispositivo de confiança
A primeira técnica permite ao malware personificar um dispositivo em que a Google já confia. No ataque Pass-ta-key básico, o malware extrai a chave de identidade do Chrome apoiada em TPM e usa as APIs de criptografia do Windows para assinar um pedido de autenticação ao autenticador na nuvem da Google, que devolve uma assertion de início de sessão válida sem pedir ao utilizador impressão digital ou PIN. O TPM continua a fazer a assinatura porque o pedido que lhe chega parece legítimo.
O sucesso deste primeiro ataque depende, contudo, do comportamento de cada site. A assertion deixa o sinalizador “User Verified” a falso, o que leva sites rigorosos como o GitHub a rejeitar a tentativa, mas a Unit 42 confirmou que outras plataformas, como o eBay, aceitaram inicialmente o início de sessão sem validar o sinalizador; o eBay já corrigiu a falha após a divulgação responsável. Além disso, o Chrome guarda metadados de credenciais sincronizadas numa base de dados local LevelDB não cifrada, dando ao malware sem privilégios um índice de todos os serviços onde a vítima usa passkeys.
Ataque 2 — Silver Pass-ta-key: registar uma chave controlada pelo atacante
A segunda técnica é mais perigosa. O Silver Pass-ta-key permite ao atacante registar a sua própria chave de verificação de utilizador no autenticador na nuvem da Google: o malware força primeiro o Chrome a voltar a registar-se, invalidando a chave de verificação existente ou eliminando o ficheiro local que contém o estado da passkey, e durante o processo de novo registo o atacante pode registar uma chave que controla, porque o autenticador na nuvem não valida se a nova chave teve origem em hardware de confiança.
Uma vez aceite a chave maliciosa pelo autenticador na nuvem da Google, o atacante pode autenticar-se a partir de outro sistema sem necessitar de mais acesso ao dispositivo da vítima, mesmo quando os sites impõem corretamente a verificação do utilizador.
Ataque 3 — Golden Pass-ta-key: roubar a chave-mestra
A terceira e mais grave técnica ataca diretamente o segredo que protege todas as passkeys. O Golden Pass-ta-key permite ao malware obter a chave-mestra usada para cifrar todas as passkeys sincronizadas através da conta Google Password Manager da vítima — o chamado Security Domain Secret (SDS) — que é enviada temporariamente ao Chrome quando um dispositivo se regista ou recupera o acesso à conta.
A Unit 42 afirmou que o malware pode despoletar o novo registo, ler o segredo da memória do processo do Chrome enquanto este permanece brevemente em texto simples, e usá-lo para recuperar as chaves privadas das passkeys sincronizadas. Quanto à dimensão: a chave-mestra que protege todas as passkeys da conta Google tem 32 bytes, e a Unit 42 mostrou que o malware, a correr como utilizador normal do Windows, sem direitos de administrador e sem qualquer aviso no ecrã, a consegue extrair da memória do processo do Chrome enquanto ali está brevemente em texto simples.
Cronologia e correções conhecidas
| Momento / entidade | Facto |
|---|---|
| Divulgação responsável | A Unit 42 comunicou as falhas à Google e reportou os problemas de verificação de utilizador aos serviços afetados antes de publicar. |
| Removeu o SDS dos registos internos FIDO do Chrome após o alerta dos investigadores. | |
| eBay | Corrigiu a falha de validação do sinalizador de verificação de utilizador. |
| GitHub | Rejeitou o pedido no teste, por validar corretamente o sinalizador. |
Os investigadores divulgaram os ataques ao Google Password Manager à Google e reportaram falhas relacionadas de verificação de utilizador aos serviços afetados, incluindo o eBay, antes de publicarem as suas conclusões. Note-se, porém, que a Google removeu o segredo dos registos após os investigadores reportarem o problema, mas a Unit 42 afirma que este continua a ser enviado ao Chrome e permanece temporariamente acessível. À data de publicação, a Google não tinha confirmado publicamente se todos os problemas identificados foram totalmente resolvidos.
Não confundir com o clickjacking dos gestores de palavras-passe
Vale a pena distinguir esta investigação de outra, anterior. Em 2025, o investigador Marek Tóth apresentou na DEF CON 33 uma técnica de DOM-based extension clickjacking que afeta gestores de palavras-passe baseados em navegador e fluxos de autenticação FIDO2/passkeys. Nesse caso, no entanto, as passkeys ficam sobretudo protegidas, uma vez que estão vinculadas ao site em que são criadas e geram assinaturas de utilização única no início de sessão. Os “Pass-ta-key” são um vetor diferente — pós-compromisso e centrado no ecossistema de sincronização da Google.
Mitigações: para operadores de sites e para utilizadores
Para quem opera serviços online, o controlo imediato é técnico. Os operadores de sites devem exigir userVerification = required e validar efetivamente o sinalizador UV devolvido, enquanto os fornecedores de credenciais precisam de atestação mais forte para novas chaves de dispositivo, proteção mais apertada do estado local das passkeys e deteção de eventos inesperados de novo registo ou recuperação.
Para cidadãos e PME, dado que o pré-requisito é o comprometimento do endpoint, a defesa começa na higiene do dispositivo:
- Manter o sistema, o Chrome e o antivírus/EDR atualizados e evitar downloads e anexos suspeitos, que são o vetor de entrada do malware.
- Perante suspeita de infeção, deixar de usar o PC para iniciar sessões e desligá-lo da rede se houver atividade desconhecida na conta em curso.
- Rever a atividade de segurança da conta Google e os dispositivos com sessão iniciada; remover dispositivos desconhecidos.
- Ponderar chaves de segurança físicas vinculadas ao hardware para contas críticas — a Unit 42 não testou todos os navegadores, sistemas operativos, gestores de palavras-passe ou chaves de segurança vinculadas a dispositivo.
Porque é que isto importa em Portugal
Para organizações portuguesas, esta investigação reforça um princípio central da segurança moderna: a proteção da identidade não substitui a proteção do endpoint. Empresas abrangidas pelo novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2) devem tratar a gestão de vulnerabilidades, a monitorização de endpoints e a resposta a incidentes como pilares obrigatórios — sob coordenação do CNCS e com apoio do CERT.PT em caso de incidente. Como o comprometimento de uma conta pode expor dados pessoais, há também implicações ao abrigo do RGPD, que obriga a medidas técnicas adequadas e à notificação de violações de dados nos prazos legais. A mensagem é equilibrada: continue a adotar passkeys pela resistência ao phishing, mas não descure a segurança da máquina onde essas passkeys vivem.
Perguntas frequentes
Devo deixar de usar passkeys por causa destes ataques?
Não. As passkeys continuam mais seguras do que as palavras-passe contra phishing. Estes ataques só funcionam se o computador já estiver comprometido por malware, pelo que a prioridade é manter o dispositivo protegido, não abandonar as passkeys.
Estes ataques podem acontecer só por visitar um site?
Não. Segundo a Unit 42, cada caminho demonstrado começa num endpoint Windows já comprometido. Não se trata de uma exploração remota ou de “zero clique” contra contas Google apenas por navegar na web.
A Google e os serviços afetados já corrigiram tudo?
Parcialmente. A Google removeu o SDS dos registos FIDO do Chrome e o eBay corrigiu a falha de validação do sinalizador de verificação. À data de publicação, a Google não confirmou publicamente se todos os problemas ficaram totalmente resolvidos.
O que devo fazer se suspeitar que o meu PC está infetado?
Deixe de usar esse computador para iniciar sessões, desligue-o da rede se houver atividade suspeita na conta, execute uma verificação completa de segurança e reveja os dispositivos com sessão iniciada na sua conta Google, removendo os que não reconhecer.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Unit 42 da Palo Alto Networks, pela BleepingComputer e em declarações das entidades envolvidas (Google, eBay, GitHub).