Passkeys não são uma armadilha

Artigo original ↗ Discussão no Hacker News ↗

Passkeys — logins sem senha baseados em criptografia de chave pública — estão sendo promovidas como uma alternativa mais segura e resistente a phishing do que senhas e códigos TOTP, mas seu impacto no mundo real continua controverso. Os comentaristas ponderam benefícios de segurança e conveniência (especialmente quando sincronizadas por grandes ecossistemas ou gerenciadores de senhas) contra preocupações sérias com aprisionamento no fornecedor, atestação sendo usada para excluir soluções abertas ou auto-hospedadas, UX confusa em múltiplos dispositivos e modos de falha na recuperação de contas. Muitos concluem que passkeys são promissoras em ambientes corporativos bem controlados ou de um único fornecedor, mas arriscadas ou prematuras como substituição universal de senhas e 2FA tradicional.

Escopo do debate

  • A maioria dos comentaristas aceita que as passkeys são, tecnicamente, uma autenticação de chave pública sólida, mas discute se o ecossistema e os padrões atuais são amigáveis ao usuário ou seguros contra abuso.
  • O fio se concentra בעיקר em: atestação e risco de aprisionamento, portabilidade, falhas de UX e diferentes modelos de ameaça em comparação com senhas+TOTP.

Atestação, aprisionamento e preocupações com “armadilha”

  • A atestação do WebAuthn permite que os sites saibam o modelo do autenticador (AAGUID) e potencialmente restrinjam quais autenticadores são permitidos.
  • Críticos argumentam que isso é um “controle” que pode ser ajustado depois: começar com configurações permissivas e, gradualmente, exigir autenticadores atestados e aprovados pelo fornecedor.
  • Exemplos concretos citados:
    • Configurações corporativas do Microsoft Entra que só permitem o Microsoft Authenticator.
    • Sistemas de e-ID suíços e austríacos listando em whitelist apenas alguns tokens de hardware.
    • Um participante do FIDO ameaçando que o comportamento não conforme do KeepassXC poderia levar ao seu bloqueio pelas relying parties.
  • Defensores respondem: as plataformas de consumo mais comuns atualmente retornam none e grandes sites não arriscariam bloquear usuários instantaneamente; alguns grandes fornecedores desencorajam publicamente a atestação para sites de consumo.
  • Céticos respondem que “não é usado ainda” não remove a capacidade, e os padrões podem evoluir sob pressão comercial ou regulatória.

Portabilidade, aprisionamento no ecossistema e backups

  • A experiência é altamente inconsistente entre Apple, Google, Microsoft, navegadores e gerenciadores de senhas.
  • Alguns relatam migração tranquila (por exemplo, Apple ↔ 1Password/Bitwarden, especificações CXF/CXP), outros encontram:
    • Nenhuma exportação genérica, apenas transferências de app para app para uma whitelist fechada de aplicativos.
    • Hardware/software explicitamente rejeitados (por exemplo, Bitwarden, KeePassXC, Linux+Firefox).
  • Muitos temem dependência de uma única conta na nuvem (iCloud/Google) e cenários de bloqueio pelo fornecedor; valorizam poder imprimir ou arquivar localmente senhas e segredos TOTP.

Benefícios de segurança vs senhas/TOTP

  • Argumentos a favor das passkeys:
    • Forte resistência a phishing: as chaves ficam vinculadas a domínios e não podem ser reutilizadas ou vazadas como senhas ou códigos TOTP.
    • Vazamentos de servidor expõem apenas chaves públicas; não há quebra de senha.
    • Para usuários não técnicos que reutilizam senhas e caem em phishing, isso é um grande ganho no mundo real.
  • Visões céticas:
    • Bons gerenciadores de senhas, com senhas únicas e TOTP, já mitigam a maior parte do risco; para esses usuários, o benefício adicional é marginal.
    • Existem ataques aos ecossistemas de passkeys (phishing de redefinição de senha/inscrição, implementações com bugs, comprometimento de dispositivos, problemas do tipo “pass-the-key”).
    • Fluxos de recuperação e fatores secundários (e-mail/SMS, códigos de backup) continuam suscetíveis a phishing, então o phishing não é eliminado, apenas deslocado.

Usabilidade, recuperação e modelos de ameaça

  • Muitos relatam passkeys como uma “bagunça confusa”:
    • Múltiplos “gerenciadores” concorrentes por dispositivo; não está claro onde uma credencial é armazenada.
    • Suporte quebrado ou incompleto em Linux, VMs, desktops remotos ou máquinas sem Bluetooth.
    • Sites lidando mal com múltiplas passkeys, misturando passkey com senha+2FA existentes de maneiras estranhas ou forçando inscrição com dark patterns.
  • Perda e recuperação:
    • As pessoas temem perder todos os dispositivos, bloqueios na conta do fornecedor ou migrações entre plataformas (iOS→Android, contas corporativas vs pessoais).
    • Fluxos apenas por hardware ou atestados levantam medo de bloqueio irreversível, em contraste com a capacidade atual de manter backups em papel e armazenamentos de senhas amigáveis à migração.
  • Os modelos de ameaça diferem:
    • Alguns priorizam phishing e ataques de commodity → preferem passkeys.
    • Outros priorizam controle, anonimato e resiliência contra abuso do fornecedor ou coerção estatal → preferem senhas+TOTP e chaves autogeridas.

Divisão entre empresa e consumidor

  • Em ambientes corporativos, muitos relatam implantações bem-sucedidas de Yubikey/passkeys com recuperação central forte, e os usuários ficam felizes em abandonar as senhas.
  • A principal ansiedade é que esses controles no estilo empresarial (atestação, whitelists, apps proprietários obrigatórios) sejam aplicados a bancos de consumo, governo e serviços “obrigatórios”.

Sentimento geral

  • Entusiastas: passkeys são uma clara melhoria, especialmente com um bom gerenciador de senhas multiplataforma; os medos em torno de atestação são exagerados.
  • Céticos: passkeys incorporam novo poder para plataformas e relying parties, a UX é frágil, a portabilidade é limitada, e o risco de “mexer no controle no futuro” faz delas uma potencial armadilha de longo prazo.