Passkeys e multi-contas em 2026: como evitar vincular contas com chaves de acesso

A partir de 1º de setembro de 2026, a Microsoft começou a incluir passkeys como método de login padrão no Entra ID, e a partir de 1º de fevereiro de 2027, desativará o envio próprio de códigos SMS e de voz. O Google tornou as chaves de acesso a opção principal de login para contas pessoais em outubro de 2023. Para uma pessoa com uma única conta, isso é conveniente. Para aqueles que gerenciam dezenas de contas em um ambiente anti-detect, a passkey facilmente se torna um fio invisível que conecta perfis isolados. Abaixo, analisamos como isso acontece e como construir um esquema em que as chaves não "vazem" entre contas.

Por que a questão surgiu agora

As passkeys existem desde 2022, mas em 2026 passaram de "pode ser ativado" para "você será solicitado". Três motivos específicos:

• Microsoft Entra ID. A partir de setembro de 2026, usuários que confirmaram o login via SMS ou chamada terão passkeys ativadas automaticamente: na próxima verificação MFA, aparecerá a opção de registrar a chave. Até 31 de janeiro de 2027, isso pode ser adiado, a partir de 1º de fevereiro de 2027, não será mais possível adiar. A Microsoft justifica com seu dado: campanhas de phishing com IA recebem 54% de cliques contra 12% das normais.
• Google. Desde outubro de 2023, nas contas pessoais, a opção "Pular a entrada de senha, quando possível" está ativada por padrão. Se a chave foi criada, o Google sugere que você faça login com ela.
• Transferência de chaves entre gerenciadores. A FIDO Alliance publicou o padrão Credential Exchange (formatos CXF e CXP). No iOS 26 e macOS 26, é possível transferir passkeys entre Apple Passwords, 1Password, Bitwarden, Dashlane e outros aplicativos de forma criptografada, sem exportar um arquivo. A chave deixou de estar rigidamente vinculada a um único armazenamento. Para multi-contas, isso é tanto uma oportunidade quanto um risco.

Como funciona a passkey e por que ela quebra a isolação dos perfis

A passkey é um par de chaves criptográficas. A chave pública é armazenada pelo site, a chave privada é armazenada pelo "autenticador". A chave está vinculada ao domínio (na especificação isso é rpId), portanto, um site de phishing não a obterá. A principal questão para multi-contas é onde fisicamente está a chave privada. O anti-detect isola cookies, localStorage, IndexedDB e impressões digitais. O armazenamento de chaves frequentemente está fora do perfil do navegador:

• Windows Hello armazena chaves no nível da conta do Windows. Qualquer navegador e qualquer perfil sob essa conta acessa o mesmo armazenamento.
• A associação de chaves do iCloud no macOS pertence ao Apple ID. Chrome e Safari em um mesmo Mac veem um único conjunto de chaves.
• O gerenciador de senhas do Google está vinculado à conta do Google na qual o navegador ou telefone está logado. Uma conta de serviço do Google para vinte perfis é um único cofre compartilhado.
• Extensões gerenciadoras (Bitwarden, 1Password e outros) armazenam chaves no cofre de sua conta. Um único cofre para todos os perfis funciona como um único ponto, através do qual tudo é visível.

Daqui surge uma falha típica. Você clica em "Entrar com a chave de acesso" no perfil da conta nº 7, e o sistema mostra as chaves das contas nº 3 e nº 12 no mesmo site. O site não vê essa lista: ele recebe apenas a chave selecionada. Mas um clique errado — e a conta nº 3 entra a partir do perfil, IP e impressão digital da conta nº 7. Essa conexão não pode mais ser desfeita.

O que o site realmente descobre ao entrar com a passkey

A passkey não elimina o risco de pontuação, ela apenas substitui a senha. Ao entrar, a plataforma ainda vê o IP, a impressão do navegador e o histórico de sessões. Além disso, recebe alguns sinais próprios do WebAuthn:

• Identificador da chave (credential ID). Ele é único para o par "conta — autenticador".
• AAGUID — identificador do modelo do autenticador. Com ele, sites como o Google assinam a chave nas configurações da conta: "criado no iCloud Keychain", "no gerenciador de senhas do Google" e assim por diante. Este não é um número único do seu dispositivo, mas é mais uma característica que deve coincidir com a lenda do perfil.
• Flags BE e BS (backup eligibility e backup state) mostram se a chave é sincronizável ou vinculada ao dispositivo.

Conclusão: um perfil "móvel" que entra com a chave do Windows Hello parece tão ilógico quanto um iPhone com o fuso horário do Brasil e IP da Alemanha. A chave deve corresponder à mesma lenda que o proxy e a impressão digital.

Esquema passo a passo: uma conta — um perfil — um armazenamento — um IP

1. Faça um inventário. Liste as plataformas onde suas contas já têm passkeys ou onde surgiu a proposta de criá-las: Google, Microsoft, grandes marketplaces e redes sociais. Nas configurações de segurança de cada conta, é possível ver quantas chaves estão registradas e onde foram criadas. Todas as entradas inesperadas "Windows Hello" e "iCloud Keychain" são candidatas à exclusão.
2. Desative o armazenamento de chaves do sistema para perfis de trabalho. No navegador onde os perfis operam, desative o salvamento de senhas e chaves de acesso no gerenciador embutido. Na máquina de trabalho, não crie chaves no Windows Hello ou na associação do iCloud. Se a janela de criação de chaves oferecer "este computador", escolha outro método.
3. Escolha um armazenamento para cada conta. A regra é simples: o armazenamento deve ser separado da mesma forma que os perfis. Opções:
   • armazenamento separado do gerenciador de senhas por conta ou por grupo de contas de um único cliente;
   • chave de hardware (FIDO2) para as contas mais valiosas;
   • para automação — autenticador de software, que será abordado no passo 6.
   Um único armazenamento para todos é a maneira mais comum de conectar contas entre si.
4. Registre a chave apenas do perfil "nativo". O mesmo perfil, a mesma impressão digital, o mesmo proxy com sessão fixada, a mesma geolocalização que durante o funcionamento normal da conta. O registro da chave é uma ação sensível, e as plataformas observam isso atentamente. Mudar o IP no meio do processo frequentemente leva a uma verificação adicional. Como manter um único endereço por perfil, discutimos detalhadamente no artigo sessão sticky ou rotação para o perfil anti-detect.
5. Deixe um método de entrada alternativo. Um armazenamento perdido significa uma conta perdida. Para cada conta, é necessário um segundo método de entrada: uma segunda passkey em outro armazenamento, uma senha com TOTP ou códigos de recuperação que são armazenados separadamente da chave. A Microsoft no Entra exige explicitamente que os usuários sejam transferidos para métodos resistentes a phishing até fevereiro de 2027. Não espere até que a janela de registro pare de se fechar.
6. Na automação, use um autenticador virtual. No Chrome DevTools Protocol, existe o domínio WebAuthn. O método addVirtualAuthenticator cria um autenticador de software com o protocolo ctap2 e transporte internal (plataforma) ou usb/hybrid. Os parâmetros hasResidentKey e hasUserVerification incluem o armazenamento da chave no autenticador e a verificação do usuário. getCredentials após o registro retorna a chave inteira: credentialId, rpId, userHandle, signCount e a chave privada no formato PKCS#8. addCredential na próxima execução a coloca de volta. Assim, obtém-se uma chave que vive apenas no seu cofre secreto e se conecta à sessão de uma conta específica. Duas ressalvas: o domínio é marcado como experimental e criado para testar o WebAuthn, e a chave privada exportada é um segredo de nível de senha, devendo ser armazenada adequadamente.
7. Transfira chaves através do Credential Exchange, e não manualmente. Se você está mudando de gerenciador ou distribuindo contas por diferentes armazenamentos, use a exportação embutida conforme o padrão FIDO: ela é suportada no Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions. Lembre-se de que no macOS, parte dos aplicativos ainda não implementou esse mecanismo.

Armadilhas

• Sincronização por padrão. A chave criada "neste dispositivo" pode imediatamente ir para a nuvem do iCloud ou Google e aparecer em todos os dispositivos dessa conta, incluindo seu telefone pessoal.
• Login cross-device via QR. O cenário "escaneie o QR com o telefone" (transporte híbrido) conecta um telefone real com suas chaves à sessão do perfil. Para perfis de trabalho, isso é uma conexão extra.
• A mesma AAGUID para toda a fazenda — isso é normal. Milhões de pessoas usam o mesmo gerenciador. O que é perigoso não é o provedor idêntico, mas a chave comum ou o armazenamento comum.
• A passkey não cura o "login sujo". Se a conta entra com um IP que já foi exposto em contas vizinhas, ou de um datacenter que a plataforma não gosta, uma forte criptografia não ajudará. O risco é avaliado pela soma dos sinais.
• O segundo fator também precisa ser isolado. Se o método de entrada alternativo for TOTP, os segredos também são distribuídos entre as contas, e não ficam em um único aplicativo no telefone pessoal. Como conectar 2FA e proxy, discutimos no material sobre autenticação de dois fatores no trabalho através de proxy.

Qual proxy é necessário e por quê

Para entrar com a chave, a consistência é o mais importante: a conta deve registrar a chave e depois entrar com ela da mesma rede, na mesma geolocalização. Portanto:

• Perfis da web em anti-detect — proxies residenciais com sessão fixa no país da conta. Esses são endereços de provedores domésticos, e eles coincidem com a lenda "usuário comum em casa".
• Plataformas móveis e contas com lenda móvel — proxies móveis. Um perfil móvel que registra a chave de uma rede doméstica do outro lado do país sai de sua história.
• Rotação a cada solicitação é adequada para scraping, mas não para login em contas. Defina um intervalo com margem para toda a sessão de trabalho.

Conclusão

As passkeys tornam o login resistente a phishing, mas transferem o ponto de conexão entre contas de cookies e senhas para o armazenamento de chaves. Esse ponto frequentemente está fora do perfil anti-detect: no Windows Hello, iCloud, conta do Google ou armazenamento compartilhado do gerenciador. O esquema de trabalho é o seguinte: cada conta tem seu perfil, seu armazenamento de chave, seu IP fixo e um método de entrada alternativo. Para automação, há um autenticador virtual no CDP. Cuide disso até fevereiro de 2027, quando a Microsoft deixará de permitir o adiamento do registro. Depois, você terá que resolver isso às pressas e diretamente em contas ativas.