Passkeys São uma Armadilha: O Que Big Tech Não Te Conta
Você provavelmente já viu aquele popup simpático no seu iPhone ou Android: “Usar passkey para fazer login?” Um toque no sensor biométrico e pronto, sem digitar senha. Parece o futuro, certo? Eu achava que sim, até que um post no Hacker News com quase mil upvotes me fez repensar tudo.
O artigo, intitulado “Passkeys are a trap”, viralizou entre desenvolvedores e profissionais de segurança por um motivo simples: ele expõe problemas que a FIDO Alliance, Google, Apple e Microsoft preferem não discutir em seus materiais de marketing. Vamos destrinchar isso.
O que são passkeys (a versão oficial)
Passkeys são credenciais criptográficas baseadas no padrão FIDO2/WebAuthn. Em vez de uma senha que você digita, o seu dispositivo gera um par de chaves: uma pública (enviada ao site) e uma privada (armazenada no seu aparelho). Na hora do login, o site envia um desafio, seu dispositivo assina com a chave privada, e o site valida com a pública. Nenhuma senha trafega pela rede, nenhum segredo é compartilhado.
Em tese, é genial. Passkeys eliminam phishing porque não existe string para roubar. Eliminam reuso de senhas porque cada credencial é única por site. Eliminam ataques de força bruta porque não existe hash para quebrar.
A FIDO Alliance vendeu essa narrativa com perfeição. Google anunciou passkeys como padrão no login em 2023. Apple integrou no iCloud Keychain. Microsoft empurrou pro Windows Hello. Todo mundo aplaudiu.
Só que a história tem camadas que ninguém te conta.
16 tipos de passkeys (e você não escolheu nenhum)
Aqui começa o problema. Quando alguém fala “passkey”, pode estar falando de pelo menos 16 combinações diferentes de propriedades:
| Propriedade | Opção A | Opção B | |
|---|---|---|---|
| — | — | — | |
| Armazenamento | Copiável (sincronizado na nuvem) | Não copiável (preso ao dispositivo) | |
| Portabilidade | Transferível entre plataformas | Não transferível | |
| Segurança | Backed por hardware (TPM/Secure Enclave) | Backed por software | |
| Verificação | Com verificação do usuário (biometria/PIN) | Sem verificação |
A combinação dessas quatro propriedades gera cenários completamente diferentes de segurança. Um passkey sincronizado pelo iCloud Keychain tem um perfil de risco totalmente diferente de um passkey hardware-bound num YubiKey. Mas os dois se chamam “passkey”.
A FIDO Alliance fez isso de propósito. Ao agrupar tudo sob um único nome amigável, facilitou a adoção, mas tornou impossível para o usuário médio entender o que está acontecendo.
Eu já vi devs seniores confundirem passkeys sincronizados com security keys físicas. Se quem constrói sistemas não entende as nuances, imagina o usuário final.
O problema real: remote attestation
Agora entra a parte que deveria preocupar todo mundo.
Passkeys suportam um mecanismo chamado remote attestation. Funciona assim: quando você registra um passkey num site, o site pode pedir uma prova criptográfica de que o seu dispositivo é “confiável”. Essa prova envolve verificação do hardware (TPM, Secure Enclave), do firmware, do sistema operacional e do software de gerenciamento de credenciais.
Na prática, isso significa que um site pode rejeitar seu login se:
- Você roda LineageOS ou GrapheneOS no celular
- Você usa um gerenciador de senhas que o site não “aprova”
- Você modificou o bootloader do seu dispositivo
- Você roda uma extensão de navegador que o site considera indesejável
Leu direito: o site pode decidir qual sistema operacional você tem permissão de usar.
Hoje, a maioria dos sites não exige attestation. Mas a infraestrutura está pronta. É como construir uma rodovia com pedágios, mas deixar a cancela aberta por enquanto. Quando alguém decidir fechar, o mecanismo já existe.
“Mas nenhum site faz isso hoje”
Essa é a resposta padrão que você ouve dos defensores de passkeys. E é verdade, em outubro de 2026, poucos sites exigem attested passkeys.
Só que a tendência é clara. Bancos já começaram a restringir quais dispositivos podem gerar passkeys válidos. Plataformas de streaming estão testando attestation para combater compartilhamento de contas. E governos, incluindo a União Europeia com o eIDAS 2.0, estão criando frameworks onde attestation seria obrigatória para serviços públicos digitais.
A analogia mais honesta é com DRM. Ninguém pediu DRM. Ninguém queria DRM. Mas foi implementado gradualmente, e hoje você não consegue assistir Netflix em 4K no Linux porque o navegador não passa na verificação de Widevine L1.
Passkeys com attestation são DRM para identidade.
Quem está na mesa (e quem não está)
A FIDO Alliance, que define os padrões de passkeys, tem membros impressionantes: Google, Apple, Microsoft, Amazon, Meta, Intel, Qualcomm, Visa, Mastercard, bancos, governos e até agências de inteligência.
Sabe quem não é membro? Nenhum grupo de defesa do consumidor. Nenhuma organização de direitos digitais. A Electronic Frontier Foundation não está lá. A Mozilla, que historicamente defende padrões abertos, tem participação limitada.
Quando um padrão de autenticação que vai afetar bilhões de pessoas é definido exclusivamente por corporações e governos, sem representação dos usuários, o resultado raramente favorece o lado mais fraco.
Vendor lock-in disfarçado de conveniência
Vamos falar de algo prático. Você cria um passkey no seu iPhone. Ele fica no iCloud Keychain. Agora você quer migrar pro Android. O que acontece?
Até meados de 2026, a resposta era: azar o seu. Cada plataforma guardava passkeys no seu próprio jardim murado. Apple no iCloud, Google no Google Password Manager, Microsoft no Windows Hello.
A FIDO Alliance criou o Credential Exchange Protocol (CXP) para resolver isso, e o iOS 26 foi a primeira plataforma a implementar. Progresso? Sim. Mas a implementação é reveladora.
Quando você registra um passkey no iOS, o sistema empurra o iCloud Keychain como opção padrão com um botão grande e bonito. Quer usar um gerenciador terceiro como 1Password ou Bitwarden? Tem que clicar em “Outras opções”, depois selecionar o gerenciador, depois confirmar. São três cliques extras, num fluxo onde a Apple sabe que a maioria dos usuários vai no caminho de menor resistência.
Dark patterns aplicados a criptografia. Eficiente.
A ilusão da segurança simplificada
Eu conversei com devs que implementaram passkeys em produção, e a história é sempre parecida: “parecia simples no marketing, ficou complexo na prática”.
Alguns problemas reais que equipes enfrentam:
Recuperação de conta é um pesadelo. Se o usuário perde o dispositivo e não configurou um segundo passkey, acabou. Não existe “esqueci minha senha” para passkeys. Algumas empresas mantêm senha como fallback, o que anula boa parte do benefício de segurança.
37% dos usuários voltam pra senha em 90 dias. Segundo dados de adoção de 2026, mais de um terço dos usuários que experimentam passkeys abandonam dentro de três meses. O motivo mais comum? Trocar de celular e perder acesso.
Credenciais somem misteriosamente. Existem relatos documentados de passkeys desaparecendo do iCloud Keychain e do Google Password Manager após atualizações de sistema. Um caso notório envolveu a conta da Dra. Paris Buttfield-Addison, que perdeu todos os passkeys após uma ação da Apple na conta dela, sem possibilidade de recuperação.
Sites implementam errado. Alguns sites usam o parâmetro authenticatorAttachment: "platform" na hora do registro, o que força o uso do gerenciador da plataforma e bloqueia security keys físicas. É como implementar HTTPS mas rejeitar certificados de CAs legítimas.
Os números que Big Tech não divulga
Vamos olhar os dados concretos de adoção. Segundo o relatório FIDO de 2026, a consciência sobre passkeys chegou a 90% dos usuários pesquisados. Parece ótimo, até você ver o próximo número: menos de 5% dos logins em grandes serviços usam passkeys de verdade.
Noventa por cento sabe o que é. Cinco por cento usa. A distância entre esses dois números conta uma história que nenhum press release da FIDO Alliance vai contar.
E mesmo entre empresas, o cenário não é animador. Menos de 30% das organizações implementaram passkeys como método primário de autenticação. Os outros 57% continuam dependendo de senhas ou outros métodos vulneráveis a phishing.
O argumento era que passkeys seriam tão fáceis que todo mundo migraria naturalmente. Três anos depois do push agressivo de Google e Apple, a adoção real conta uma história diferente: a tecnologia é boa demais no papel e confusa demais na prática.
Biometria: o mito que não morre
Outro problema que devs de segurança apontam constantemente: muitos serviços comunicam passkeys como se a biometria fosse transmitida pela internet. “Faça login com sua digital” ou “Use seu rosto para entrar” são frases que induzem o usuário a pensar que dados biométricos estão sendo enviados ao servidor.
Na realidade, a biometria serve apenas para desbloquear a chave privada localmente. Nenhum dado biométrico sai do dispositivo. Mas a comunicação errada gera dois efeitos ruins: usuários preocupados com privacidade rejeitam passkeys por motivos errados, e usuários despreocupados acham que biometria é o mecanismo de segurança (quando na verdade é só o desbloqueio).
Se a indústria não consegue nem comunicar direito como a tecnologia funciona, talvez ela não esteja pronta pra ser o padrão universal de autenticação.
O que funciona melhor (e ninguém quer ouvir)
TOTP. Sim, aqueles códigos de seis dígitos que mudam a cada 30 segundos.
Eu sei, não é sexy. Não tem biometria, não tem animação bonita no celular. Mas TOTP tem vantagens que passkeys não têm:
TOTP (RFC 6238)
├── Padrão aberto, implementável por qualquer software
├── Funciona offline (baseado no relógio)
├── Portável: exporta/importa entre qualquer app
├── Se vazar, expira em 30 segundos
├── Nenhum vendor lock-in
└── Roda até num Game Boy (não estou brincando)
Passkeys (FIDO2/WebAuthn)
├── Padrão controlado pela FIDO Alliance
├── Requer conectividade (para attestation)
├── Portabilidade limitada (CXP ainda nascendo)
├── Se comprometido, acesso permanente até revogar
├── Lock-in por design (plataforma > usuário)
└── Requer hardware moderno com TPM/Secure Enclave
TOTP não protege contra phishing, é verdade. Mas combinado com um gerenciador de senhas que preenche automaticamente (e verifica o domínio), o risco cai drasticamente. E você mantém controle total sobre suas credenciais.
Para quem quer o melhor dos dois mundos, security keys físicas como YubiKey oferecem resistência a phishing sem os problemas de vendor lock-in e remote attestation. Você compra o dispositivo, ele é seu, ninguém controla remotamente o que ele faz.
O cenário que ninguém quer imaginar
Vou pintar um cenário hipotético (mas tecnicamente viável com a infraestrutura atual de passkeys):
- Seu banco exige login com passkey atestado
- A attestation requer um sistema operacional “aprovado”
- Você usa GrapheneOS por privacidade
- O banco rejeita seu passkey porque o OS não é “confiável”
- Você precisa comprar um iPhone ou Pixel com Android stock para acessar sua conta bancária
Parece distópico? DRM no streaming já funciona exatamente assim. Você não assiste Disney+ em 4K num Chromebook com Linux. A diferença é que streaming é entretenimento. Banco é necessidade.
Agora escala isso para serviços governamentais. Declaração de imposto. Acesso ao sistema de saúde. Votação eletrônica. Com attestation, o governo pode tecnicamente exigir que você use um dispositivo “aprovado” para exercer direitos básicos.
O que eu faço com tudo isso?
Eu não estou dizendo “nunca use passkeys”. Se você tem um iPhone, usa iCloud Keychain e não pretende sair do ecossistema Apple, passkeys funcionam bem como segundo fator.
Mas:
- Nunca use passkeys como único método de autenticação. Sempre mantenha uma senha forte + TOTP como backup.
- Prefira security keys físicas se você leva segurança a sério. Um YubiKey custa menos que um jantar e dura anos.
- Desconfie de sites que só aceitam passkeys da plataforma. Se um site bloqueia security keys, ele está priorizando o interesse da plataforma, não a sua segurança.
- Exporte seus passkeys se o seu gerenciador suporta. 1Password e Bitwarden já permitem exportação. Faça backups.
- Acompanhe o debate sobre attestation. Quando (não se) sites começarem a exigir attested passkeys, você precisa saber o que está em jogo.
Quem vigia os vigias?
A FIDO Alliance promete que passkeys são o futuro da autenticação. E talvez sejam. Mas é um futuro onde Big Tech define quem pode se autenticar, em quais dispositivos, rodando qual software.
Eu prefiro um futuro onde a autenticação é um padrão aberto, controlado pelo usuário, sem gates corporativos. TOTP prova que isso funciona. Security keys provam que isso pode ser seguro contra phishing.
Passkeys, como estão hoje, são uma solução elegante com um cavalo de Troia dentro. O login é bonito. O que vem depois, nem tanto.
A próxima vez que aquele popup aparecer no seu celular pedindo pra criar um passkey, pense duas vezes. Não porque a criptografia é ruim. Ela é excelente. Mas porque conveniência sem controle é só outra palavra pra dependência.
—
Fonte de inspiração: Passkeys are a trap, viral no Hacker News com 972 upvotes













