Passkeys – Nos Bastidores

Chaves não residentes vs. residentes / passkeys

  • Chaves WebAuthn/U2F não residentes derivam pares de chaves por site a partir de um único segredo usando um identificador armazenado no servidor; o token permanece quase sem estado, pode suportar sites “ilimitados” e não vaza informações sobre onde é usado.
  • Chaves residentes (“credenciais descobríveis” / passkeys) precisam armazenar entradas por site no autenticador para permitir login sem nome de usuário, criando limites de capacidade (dezenas a poucas centenas de slots) e possíveis problemas de privacidade (o autenticador pode ser consultado para saber se existe uma conta para um domínio).
  • Vários comentaristas argumentam que passkeys são uma regressão em relação a senhas fortes e únicas + 2FA por hardware, especialmente quando sites deixam de oferecer suporte a WebAuthn não residente.

Trade-offs entre segurança e usabilidade

  • Para usuários com senhas fracas ou reutilizadas, passkeys são vistas como uma grande melhoria (resistência a phishing, sem vazamentos de senha).
  • Para usuários preocupados com segurança que já usam chaves de hardware e gerenciadores de senhas, passkeys podem reduzir a flexibilidade ou a segurança (um único fator, sincronizáveis, attestation limitada).
  • Alguns observam que é possível evitar enumeração de contas com chaves não residentes enviando identificadores fictícios, então “precisar de senhas primeiro” não é estritamente verdade.

Tokens de hardware vs. passkeys sincronizadas

  • Chaves de hardware: forte isolamento, attestation, presença física, PINs, boa opção para ambientes regulados / de alto valor; mas custo, risco de perda da chave, gerenciamento de chaves pelo usuário e armazenamento residente limitado são problemas reais.
  • Passkeys em telefones/enclaves seguros com sincronização em nuvem são vistas como a única opção escalável para o público em geral; a maioria dos usuários não vai gerenciar tokens separados ou backups.
  • Há a preocupação de que o trabalho com FIDO/WebAuthn esteja cada vez mais otimizado para passkeys de plataforma, tornando autenticadores de hardware itinerantes uma solução de segunda classe.

Fragmentação do ecossistema e UX

  • O suporte em navegadores e sistemas operacionais é inconsistente (por exemplo, Firefox mobile, flags do Chrome, detecção por user agent); alguns sites lidam mal com WebAuthn, restringem chaves itinerantes ou usam fluxos de UX de forma inadequada.
  • Gerenciadores de senhas estão cada vez mais oferecendo suporte a passkeys (desktop e mobile), mas a integração e os fluxos (por exemplo, prompts, preenchimento automático, fallback para o navegador) ainda são ásperos.
  • Explicar o básico “use seu rosto/impressão digital para entrar” é fácil; explicar recuperação, migração entre plataformas e quando senhas ainda são necessárias é visto como difícil e pouco especificado.

Attestation e controle

  • Tokens de hardware fornecem attestation forte; alguns setores regulados dependem disso.
  • Implementações importantes de passkeys em plataformas desativaram ou limitaram a attestation para credenciais sincronizadas, frustrando esses casos de uso.
  • Outros argumentam que a falta de attestation é benéfica para a liberdade do usuário e contra controle no estilo DRM, destacando uma tensão fundamental entre controle corporativo e autonomia do usuário.