Como o hype em torno das Passkeys está tornando as chaves de segurança inúteis

• Se se espalhar a tendência de definir Passkeys como resident keys e exigi-las, chaves de segurança como Yubikey, Feitian e Nitrokey rapidamente esbarrarão em limites por causa do espaço de armazenamento limitado
• A non-resident credential funciona de modo que a chave de segurança descriptografa o credential ID fornecido pela Relying Party para obter a chave privada específica da RP, então apenas a master key fica armazenada no dispositivo
• Já a resident/discoverable credential armazena a própria chave privada na chave de segurança, consumindo um slot por conta; a Nitrokey suporta 8 e a Yubikey normalmente só 20 a 32
• Chaves de segurança CTAP2.0 não permitem apagar resident keys individualmente, exigindo reset completo; nesse processo, a master key também muda, fazendo até as non-resident keys existentes deixarem de funcionar
• Se serviços e bibliotecas passarem a exigir resident keys por padrão, usuários com mais de 150 contas terão de gerenciar várias chaves de segurança e chaves de backup, dificultando a livre escolha do autenticador desejado

---

Por que a resident key está no centro do problema

• O ponto central da preocupação de que o hype em torno das Passkeys possa transformar chaves de segurança em dispositivos obsoletos está na resident key
• A percepção de que chaves de segurança suportam um número “ilimitado” de contas muitas vezes depende do modelo de non-resident credential
• Como a resident key realmente consome espaço interno da chave de segurança, o limite do dispositivo aparece imediatamente à medida que o número de contas cresce

Como funciona a non-resident credential

• Na non-resident credential, a Relying Party envia o credential ID para a chave de segurança por meio do navegador durante a autenticação
• O credential ID é um blob criptografado que só a chave de segurança consegue descriptografar, e o resultado da descriptografia é a chave privada exclusiva daquela Relying Party
• A chave de segurança assina o challenge com a chave privada descriptografada e devolve a assinatura ao navegador e à Relying Party
• Nessa estrutura, a chave privada não fica residente no enclave seguro, e apenas a master key permanece dentro da chave de segurança
• O credential ID é criptografado com AES-128 e protegido com HMAC, sendo considerado difícil de adulterar ou descriptografar externamente
  • A comparação feita é que, se o AES-128 fosse quebrado a ponto de permitir descriptografar a chave privada sem a chave de segurança, então TLS e SSH também já estariam em um nível semelhante de exposição a ataques

A diferença da resident/discoverable credential

• A resident key, ou discoverable credential, é um modelo em que a chave privada é armazenada dentro da chave de segurança
• Quando a Relying Party envia uma lista vazia de credential IDs, a chave de segurança encontra uma chave utilizável para aquela RP, seleciona e assina
• Essa estrutura não depende de receber externamente um credential ID para descriptografá-lo com a master key
• Em troca, cada credential ocupa espaço interno da chave de segurança, então o número de slots de resident key se torna o limite real de contas

userVerification é separado de resident key

• Existe a confusão de que, para uma credential impor userVerification, ela necessariamente precisa ser resident, mas os dois conceitos são separados
• A chave de segurança não apenas confirma presença com toque, como também pode verificar PIN ou biometria internamente para confirmar que é o usuário real
• Esse comportamento é controlado pela userVerification flag e funciona independentemente da residência da key
• Portanto, mesmo sem ser resident key, o dispositivo ainda pode funcionar por conta própria como um autenticador multifator

Espaço de armazenamento das chaves de segurança e limitações do CTAP

• Como a resident key é armazenada no dispositivo, o número de slots da chave de segurança é importante
  • A Nitrokey suporta 8 resident keys
  • A Yubikey geralmente suporta de 20 a 32
  • Algumas chaves nem sequer suportam resident key
• O padrão CTAP implementado pela chave de segurança também influencia fortemente a capacidade de gerenciamento
  • CTAP2.1 e CTAP2.1PRE permitem gerenciar, atualizar e apagar resident keys individualmente
  • CTAP2.0 exige reset completo do dispositivo para apagar uma resident key
• Como o reset de um dispositivo CTAP2.0 também reinicializa a master key, até as non-resident keys existentes deixam de funcionar
• É provável que muitas chaves de segurança sejam CTAP2.0, e no caso da Yubico a versão do CTAP varia conforme a versão do firmware

O nome passkeys e a difusão da definição de resident key

• Em 2022, a Apple anunciou no macOS/iOS o recurso passkeys, que usa Touch ID e Face ID como autenticadores WebAuthn
• O nome passkeys é visto como mais amigável para o usuário do que “webauthn authenticator” ou “security key”
• Depois disso, várias interpretações surgiram sem que o significado de passkeys tivesse sido claramente fixado
  • A biblioteca Rust WebAuthn e implementadores de Relying Party definem passkeys como o nome de qualquer autenticador que o usuário possa escolher
  • Alguns membros da comunidade chamaram de passkeys as credentials sincronizadas entre vários dispositivos
  • Na conferência FIDO Authenticate surgiu a definição de que “passkey é resident key”, e depois a própria FIDO passou a usar essa definição no FAQ
• Um dos motivos para a definição de resident key ganhar atenção é sua ligação com um recurso futuro dos navegadores, a conditional UI
  • Se a credential for uma resident key, o nome de usuário e a credential WebAuthn podem ser preenchidos automaticamente
  • Isso oferece uma experiência em que o usuário não precisa digitar o nome de usuário manualmente

Problemas para o usuário causados pela exigência de resident key

• Se bibliotecas WebAuthn passarem a induzir o uso de resident key em todos os registros, chaves de segurança com armazenamento limitado podem lotar rapidamente
• Por exemplo, se houver mais de 150 senhas salvas em um gerenciador de senhas, convertê-las todas em resident keys exigiria pelo menos 5 Yubikeys
• Considerando backups, talvez seja necessário gerenciar de 10 a 15 Yubikeys
• Isso gera uma experiência ruim para quem escolheu usar chaves de segurança, e a exigência de resident key nas passkeys pode acabar dificultando o próprio uso dessas chaves
• No marketing de chaves de autenticação FIDO aparecem frases como “armazenamento infinito de key pairs” ou “sem limite de contas registradas”, mas isso pode ser verdade para non-resident keys e ainda assim entrar em conflito com a exigência de resident key
• Um dos objetivos do WebAuthn Work Group é permitir que usuários escolham livremente o autenticador que desejam sem desvantagens, mas forçar resident key não combina com esse objetivo
• Como tipos de autenticador que funcionariam bem em um ambiente de passkeys, são citados Apple passkeys, Android passkeys, gerenciadores de senhas com suporte a WebAuthn, Windows com TPM 2.0 e navegadores baseados em Chromium no macOS usando Touch ID como se fosse um TPM

Possíveis caminhos de resposta

• Há uma proposta de mudar o comportamento de rk=preferred para que chaves de segurança não criem resident keys
  • Hoje, a Relying Party pode definir o nível de solicitação de resident key como discouraged, preferred ou required
  • Atualmente, rk=preferred cria resident keys até mesmo em autenticadores roaming como Yubikey, e no fim funciona de forma parecida com rk=required
  • Se preferred fosse flexibilizado para “criar resident key apenas quando o armazenamento for ilimitado”, Android/iOS criariam resident keys, enquanto o espaço das chaves de segurança não seria consumido
  • O WebAuthn WG ainda resiste a essa mudança, e para navegadores implementarem isso separadamente, na prática a decisão dependeria da equipe do Chrome
• Outra possibilidade é exigir que bibliotecas de passkeys usem rk=discouraged
  • rk=required pode excluir chaves de segurança
  • rk=discouraged pode impedir que usuários Android obtenham conditional UI
  • Como já existem meios de preenchimento automático para nomes de usuário, isso seria considerado melhor do que excluir chaves de segurança
• Também existe a proposta de pedir à FIDO que torne o espaço de armazenamento de resident keys um requisito de certificação
  • Hoje a FIDO não impõe exigências de capacidade de armazenamento para dispositivos autenticadores
  • O argumento é que, se a FIDO quer resident keys, então deveria exigir que autenticadores certificados pudessem armazenar milhares delas

Conclusão

• A tendência exagerada de tratar passkeys como resident keys pode impedir ou tornar muito mais difícil para usuários de chaves de segurança escolherem online o autenticador que desejam
• O problema não está tanto nas passkeys em si, mas em aplicar de forma generalizada a exigência de resident key a chaves de segurança com espaço de armazenamento e recursos de gerenciamento limitados

[GN⁺]

Opiniões no Hacker News

• Isto é um pouco diferente de criptografia em si, mas minha mãe me ligou em pânico porque não conseguia entrar no Gmail. No fim, o Google tinha registrado automaticamente o novo celular Android dela como uma passkey e mudado isso para o método padrão de login, mas a interface era confusa demais
  Acho exagero esperar que, para fazer login com senha, a pessoa tenha que clicar na segunda opção ou entender o que é uma passkey. Dizia que “enviou uma passkey para o Android”, mas nenhuma notificação apareceu no celular, e mesmo depois de 30 minutos não conseguimos resolver. Não dava nem para apagar a passkey registrada automaticamente, nem para desativar o fluxo de autenticação padrão. A UX do Google é terrível, e confiar em uma variante modificada do Android em celulares Samsung de baixo custo como base para um sistema de autenticação em larga escala parece uma decisão burra

  • Há o mesmo problema na verificação em duas etapas do Google. Ele diz “enviamos uma notificação para o S21”, mas, na prática, mesmo com o S21 desbloqueado na mão, em 1 de cada 3 vezes a notificação não chega, ou só chega 5 minutos depois
    É só mais um dos vários problemas que tive recentemente com o Google. Antes eu tentava evitar meio por alto por causa de privacidade; agora estou me esforçando ao máximo para reduzir o uso do Google. No Google Maps, uma empresa foi removida sem motivo algum e levou 2 semanas para cadastrá-la de novo; falar com uma pessoa era impossível. Cada e-mail de suporte fornece um número de telefone, mas é o número do suporte de anúncios, que não consegue fazer nada por uma conta empresarial suspensa, e eles nem queriam acreditar que a equipe do Google Business fornecia aquele número como suporte. Tive que repetir perguntas por 30 minutos até que um funcionário do suporte do Google Ads admitisse que não havia como falar com alguém relacionado ao Google Business. Agora virei simplesmente um evangelista anti-Google
  • Por causa das solicitações indesejadas de confirmação do tipo “enviamos uma notificação para o seu celular”, estou considerando seriamente tirar meu negócio do ecossistema do Google. Eu entenderia se eu estivesse fazendo login de repente do outro lado do planeta, ou se sempre usasse Linux e o navegador fosse identificado como Windows, mas, quando uso o ungoogled chromium, um navegador focado em privacidade, isso acontece em toda autenticação, mesmo no mesmo IP
    E se a bateria do celular acabar? E se eu perder o celular e precisar recuperar as credenciais de serviço de localização enviando uma redefinição de senha por e-mail, mas não conseguir entrar no e-mail? Aí começa o processo de “responder às perguntas”. Um algoritmo obscuro e sem responsabilidade decide que o ungoogled chromium no Linux é suspeito, e se você lembrar errado a resposta a perguntas como “qual porcentagem do armazenamento atualmente disponível você está usando?”, recuperar o acesso fica por conta da sorte. Para constar, sou usuário pagante do Google
  • Uma pequena correção: a passkey não é “enviada” para o Android. O login no Gmail funciona fazendo você escanear um QR code exibido no navegador para provar que possui a passkey no Android
    Ainda assim, entendo totalmente o ponto. A UX e a terminologia são confusas. Mesmo que cada etapa ofereça explicações, isso não ajuda muito, porque as pessoas são treinadas, especialmente quando estão com pressa, a pular textos explicativos pequenos e apertar o botão maior e mais chamativo. É um problema realmente difícil de design de UX
  • Depois disso, passou do limite para mim. Percebi que o Google não toma decisões com base nos usuários. Ele ganha dinheiro com anunciantes, oferece serviços só o bastante para que os usuários não saiam e se mantém apenas o suficiente para bloquear concorrentes
    Enquanto os usuários não forem embora, o Google não se importa, nem precisa se importar. Se você quer algo diferente, precisa de serviços que não sejam pagos por anunciantes. Se o Google explora os usuários de um jeito, a Apple apenas os explora de outro; escolher o veneno não é uma opção
  • Sendo justo, isso não é um problema das passkeys em si, mas algo mais próximo de uma UX de produto idiota do Google. Se o Google muda de repente a UX de login para uma forma com a qual os usuários não estão acostumados, a maioria inevitavelmente vai ficar confusa

• Como a Apple não definiu isso de fato, pensadores acabaram preenchendo a lacuna para usuários que querem saber: “afinal, o que é uma passkey?”
  Eu sempre entendi que a Apple definia passkeys como pares de chaves sincronizados pelo iCloud Keychain. Na apresentação da WWDC 2021, as passkeys também foram diferenciadas das chaves de segurança porque você “sempre as tem”, ou seja, por causa da sincronização entre dispositivos e por serem “recuperáveis”. Depois, a definição parece ter se expandido para outros métodos de sincronização em nuvem. Acho que este texto faz um compromisso errado. Chaves de segurança não são importantes[1]. Isso porque só são usadas por um número muito pequeno de usuários técnicos e por poucas empresas que realmente priorizam segurança. Para aumentar a segurança da web, precisamos tirar as pessoas das senhas, e 99% da população não vai usar chaves de segurança a menos que seja obrigada. As passkeys têm grande probabilidade de substituir senhas, especialmente graças à integração profunda com o sistema operacional. Não se deve otimizar a autenticação para usuários de 1% ou menos só porque faltam slots de chaves residentes. [1] Tenho 3 Yubikeys, 3 chaves de segurança Yubico e 1 SoloKey

  • O objetivo não era o produto Apple Passkey, mas uma iniciativa em nível de setor. Por volta do lançamento em 2022, a definição tinha ficado mais flexível, aproximando-se, por exemplo, de uma “experiência” que fosse detectável e oferecesse opções de verificação do usuário
    O usuário pode escolher se quer usar um provedor de passkeys com backup e recuperação, e a parte confiável recebe esse sinal. Com base nesse sinal, ela também pode decidir se sugere remover a opção de login por senha
  • Na verdade, passkeys são definidas pela FIDO Alliance
    Segundo o padrão FIDO, passkeys substituem senhas e permitem que os usuários façam login em sites e apps de forma mais rápida, fácil e segura em seus vários dispositivos. Ao contrário das senhas, passkeys são sempre fortes e resistentes a phishing. https://fidoalliance.org/passkeys/

• Não entendo por que rk=required existe. Para começo de conversa, isso nem deveria existir como opção
  É por causa de coisas assim que continuo preocupado e cético em relação às passkeys e às pessoas envolvidas nelas. Elas têm a responsabilidade de projetar o protocolo de modo que ele não se torne uma ferramenta conveniente para todo tipo de prática de mercado maliciosa com que grandes empresas como a Microsoft destroem seriamente a segurança, a compatibilidade e a concorrência. Mas a atitude que aparece repetidamente em textos e posts parece mais próxima de “que se dane, vamos facilitar ainda mais o abuso”. Não é só uma questão de chaves residentes; por exemplo, a forma como a attestação é tratada também pode ser facilmente abusada para acabar com empresas

  • O objetivo aqui parece ser transformar o celular em uma passkey e fazer com que nada além disso seja usado. Visto por esse ângulo, tudo no texto faz sentido
  • Acho isso menos ruim do que o abuso de attestação
    Se um serviço define rk=required e a plataforma não quer, não consegue ou não tem como ativar ou oferecer suporte a isso, o processo sempre falharia e a pessoa nem conseguiria se cadastrar. Se o objetivo é integrar usuários e fazer o negócio crescer, parece um tiro no próprio pé
  • Fiquei curioso sobre qual é o problema em “a forma como a attestação é tratada pode ser facilmente abusada para acabar com empresas”

• Não sou de segurança nem de criptografia, então achei este texto muito difícil de acompanhar, e imagino que outras pessoas também achem
  Para quem tem conhecimento de base suficiente, talvez pareçam perguntas estranhas, mas eu travo a cada uma ou duas frases. Não entendo como, nem por que, “no fim tudo se resume a uma coisa: chaves residentes”, nem a conexão disso com passkeys ou HSMs. A frase “é preciso entender o que são chaves descobríveis/residentes” fica ambígua: quer dizer que todas as chaves residentes são chaves descobríveis, que todas as chaves descobríveis são chaves residentes, ou as duas coisas? Quando diz que “a maioria das chaves dá suporte a contas ‘ilimitadas’”, não sei se “chaves” aqui são passkeys, chaves armazenadas em HSMs ou ambas. E também fico confuso se “enviar uma chave encapsulada por outra chave para a chave de segurança” quer dizer que o motivo de HSMs poderem ser aplicados a contas ilimitadas é que é possível encapsular e armazenar uma chave com outra chave

  • O ponto central parece ser que o WebAuthn está sendo empurrado para um modelo de passkey em que cada site cria credenciais que consomem armazenamento. Nome de site exibível, nome da conta do usuário, handle do registro do usuário, chave privada e outros itens, tudo isso ocupa espaço
    Um celular consegue armazenar 10 mil passkeys sem problema, mas uma chave de hardware moderna pode armazenar apenas 25 no total na flash disponível. A razão de esse armazenamento ser necessário é a descobribilidade. Por exemplo, se você clica no novo suporte a passkeys na página de login do GitHub.com, consegue entrar sem sequer digitar o nome da conta. O navegador oferece uma experiência parecida com a de um gerenciador de senhas, e a passkey se torna localmente um registro da conta do site, como uma senha dentro do gerenciador de senhas. Mas o WebAuthn também tem vários modos que não são passkeys. Credenciais não descobríveis exigem que seja fornecida uma lista de handles para uma conta de usuário específica, e esses handles são os que a chave forneceu no registro. Na autenticação, apenas as credenciais que correspondem aos handles são apresentadas como opções. Chaves de segurança de hardware aproveitam isso armazenando no próprio handle o registro necessário para operações criptográficas futuras; esse modo não usa armazenamento flash. Quando o usuário digita o nome de usuário, alguma API retorna a lista de handles, e isso é aplicado à chave de segurança para autenticar sem limite de armazenamento. Só que muitos sites adotam a política de não expor se uma conta existe. Você já deve ter visto fluxos de recuperação do tipo “se esta conta existir, você receberá um e-mail em breve”. Para os sites, pode ser difícil aceitar um fluxo de login que oferece uma API capaz de detectar se há uma conta vinculada a um nome de usuário ou e-mail e quantas credenciais estão registradas. No fim, parece mais provável que surjam chaves de segurança com 10 vezes mais armazenamento do que os sites adotarem amplamente esse fluxo e influenciarem as limitações atuais de hardware
  • Concordo que a argumentação do texto não é boa. O ponto central é a afirmação de que, no protocolo WebAuthN, a capacidade de a parte confiável especificar rk=required é prejudicial. Isso porque impede muito hardware TPM de funcionar como carteira/banco de dados de passkeys
    Acho que a maioria dos comentários concordaria com isso. Ainda assim, isso não justifica a confusão criada pelo autor ao gastar metade do texto discutindo a definição de passkey
  • O texto pressupõe bastante conhecimento de FIDO2, então é natural que seja confuso
    Passkeys são implementadas sobre FIDO2 e, em especial, usam o recurso de chaves residentes da especificação FIDO2. Dispositivos autenticadores de hardware FIDO2 não são exatamente HSMs, mas são parecidos, e há dispositivos, como Yubikeys, que são HSMs e também autenticadores FIDO2. Em FIDO2, “chave residente” e “chave descobrível” são sinônimos. A especificação usa “chave residente”, mas “chave descobrível” também é comum, e isso é uma das terminologias confusas criadas pela FIDO. “Chave” aqui não se refere a uma passkey nem a uma chave armazenada em um HSM, mas a um dispositivo autenticador de hardware FIDO2, como uma Yubikey, normalmente chamado de “chave de segurança”. Um dispositivo autenticador de hardware FIDO2, enquanto não usa chaves residentes, é na prática sem estado e não armazena nada, por isso pode ser registrado em um número ilimitado de contas. Ao ser registrado em uma conta, o dispositivo gera um par de chaves, como EdDSA, mas não o armazena; em vez disso, criptografa a chave privada com uma chave mestra interna, por exemplo uma chave AES256. Em seguida, envia a chave pública em texto claro e a chave privada criptografada para uma parte confiável, como google.com, armazená-las. Na autenticação, a chave privada criptografada, isto é, a chave “encapsulada”, é enviada ao autenticador, descriptografada dentro do dispositivo e usada para produzir uma assinatura digital. No entanto, FIDO2 não especifica de fato como implementar chaves não residentes; chaves encapsuladas são apenas uma forma. FIDO2 exige apenas que a chave privada possa ser derivada de forma segura a partir do ID da credencial, e o ID da credencial é um dado arbitrário que pode ou não ser uma chave encapsulada

• Acho que estão vendo a situação de forma dura demais. Se você quer aproveitar os benefícios de um novo padrão de autenticação que elimina senhas fracas e reutilização de senhas, impedindo 99% das invasões de contas do dia a dia, também dá para dizer que precisa sair do Yubikey antigo que vinha resistindo desde 2013 e gastar US$ 30 para fazer um upgrade

  • Não entendo por que eu deveria ser forçado a fazer upgrade. Chaves não residentes também eliminam senhas fracas e reutilização de senhas. Chaves residentes só acrescentam uma pequena melhoria, no sentido de que, ao inserir a chave, o serviço sabe a qual conta ela pertence, e isso não me parece uma justificativa para descartar todos os dispositivos de autenticação existentes que estão em uso hoje
  • Olhando o manual técnico da série 5, ela só suporta 25. Por enquanto tenho apenas 2, mas tenho muito mais TOTPs do que 25
    Não sei como é no modelo Bio FIDO, mas, se for parecido, talvez a YubiCo não tenha um produto adequado para um grande número de chaves residentes. Correção: o Bio também tem o mesmo limite de 25
  • Para mim, isso parece até uma interpretação favorável demais
    Chaves residentes compartilhadas não deveriam existir, exceto para uso temporário de curto prazo. Isso é uma responsabilidade, um risco de segurança e incentiva más práticas de segurança. O melhor exemplo é o TOTP, que tem muitas falhas do ponto de vista de segurança. Você não deveria querer compartilhar ou fazer backup de segredos compartilhados em vários dispositivos, mas o fato de isso ser possível, junto com implementações frouxas de autenticação de dois fatores terem virado o padrão em vez da exceção, faz com que isso seja praticamente imposto. Pelo rumo atual, acho que as passkeys vão seguir a mesma direção cheia de falhas e hostil ao usuário
  • Ainda assim, isso não muda muita coisa. Minha chave só comporta 25 chaves residentes, enquanto tenho mais de 25 senhas salvas no gerenciador de senhas
  • Tenho receio de que, no futuro, não haja escolha além de adotar essa “vantagem”. Quando um site implementar o novo padrão de autenticação, ele também vai continuar mantendo o usuário/senha/autenticação de dois fatores atuais como alternativa?

• Autenticação baseada em “algo que você possui, mas pode perder” é fundamentalmente quebrada. Se você perde o dispositivo, perde o acesso; ou então o ponto mais fraco precisa estar em outro lugar, e essa segurança excelente deixa de significar algo

  • Basta imprimir códigos de backup ou adicionar uma segunda chave de gaveta. A ideia em si é ótima, mas o marketing é muito ruim, o fluxo de configuração é estranho para usuários comuns, e empurrar chaves que podem ser transferidas por AirDrop ou sincronizadas na nuvem também é uma má ideia. O problema mais importante é o custo das chaves
  • Senhas também não entram nisso? As pessoas também perdem senhas com frequência
    O resultado vai provar, mas, se as passkeys forem amplamente adotadas, acho que, para a maioria, bloqueios de conta ficarão menos comuns, não mais comuns

• Fico curioso por que o armazenamento das chaves de hardware é tão limitado. Quanto custaria a mais colocar dentro da chave um dispositivo de armazenamento de grande capacidade que o processador seguro pudesse acessar?
  Naturalmente, esse armazenamento de grande capacidade seria fortemente criptografado pelo processador seguro, e bastaria apagar também essa chave quando tudo fosse apagado

  • Porque armazenamento inviolável seguro é caro
    Do ponto de vista de segurança, dá até para dizer que uma chave de segurança com armazenamento zero é a melhor chave de segurança. Protocolos que não derivam tokens de segurança de segredos compartilhados etc., mas os injetam e armazenam em uma chave de segurança ou enclave seguro, em geral tiveram falhas graves. Às vezes é uma falha de segurança fundamental, como no TOTP, e às vezes é uma falha de complexidade. Da mesma forma, você nunca deveria querer compartilhar uma chave de segurança para HSK/autenticação de dois fatores entre vários dispositivos. Se ela vazar em um dispositivo, tudo estará comprometido. Em vez disso, cada dispositivo deve ter uma chave separada, e para o provedor de login ou o lado do servidor esse overhead é desprezível no panorama geral
  • Parece uma escolha de design consciente para manter esses dispositivos o mais “burros” possível. No momento em que você adiciona armazenamento, abre a mesma superfície de vulnerabilidades de outros dispositivos de armazenamento; depois vêm recursos de computação e, no fim, deixa de ser um Yubikey burro para virar um computador completo
  • Dá para aumentar o armazenamento, mas, quanto mais você coloca, maior a chance de falha. As chaves atuais aguentam um uso bastante agressivo antes de parar de funcionar
    Armazenamento pequeno também tem a vantagem de ser um pouco mais fácil de auditar. Claro que, pelos padrões atuais, até esse tamanho pequeno talvez já esteja forçando os limites do que é realisticamente auditável
  • Não é tanto que a memória seja limitada; é mais que ela foi projetada desde o início para não ter limite de memória
    Olhando para um TPM, toda vez que você assina algo, a entrada é o dado a ser assinado e a chave privada selada. A chave selada é uma chave privada gerada pelo TPM, criptografada simetricamente com uma chave embutida no TPM. Você armazena essa chave selada em um dispositivo de armazenamento de grande capacidade e a fornece ao TPM a cada operação de assinatura. Graças a esse design, você pode ter tantas chaves quanto o armazenamento de grande capacidade permitir
  • Acho que também daria para fazer isso de forma modular. Algo como vender um produto com aparência de pendrive USB, mas com um slot na parte de trás para encaixar uma chave de segurança de formato pequeno, como uma YubiKey Nano
    Ao encaixar a chave de segurança no slot, o pendrive USB forneceria armazenamento para a chave de segurança e, para o computador, pareceria uma chave de segurança. Quando a chave de segurança não estivesse encaixada, funcionaria como um pendrive USB comum. No uso normal, você deixaria a chave de segurança encaixada; quando precisasse de mais armazenamento, compraria um módulo de armazenamento maior, removeria a chave de segurança do módulo antigo, conectaria ao computador para copiar os arquivos criptografados, moveria tudo para o novo módulo e encaixaria a chave de segurança de volta

• Para começo de conversa, não sei se usar uma chave de segurança física como passkey é uma boa ideia. Passkeys foram pensadas como substitutas de senhas e, para isso, parecem precisar das propriedades de dois fatores oferecidas por um celular ou desktop que, além de “algo que você tem”, exige “algo que você sabe” ou “algo que você é” para desbloquear
  Acho melhor deixar as chaves de segurança físicas como uma autenticação em duas etapas usada além das passkeys em certos contextos de alta segurança. Especialmente quando a resistência à cópia é o recurso principal. Para esse uso, quando se chega à segunda etapa, você já sabe em qual conta está tentando fazer login, então não precisa de chaves residentes. Além disso, acho que o recurso de preenchimento automático fornecido por chaves residentes é importante para a UX de passkeys. Não faz sentido sacrificar isso para manter compatibilidade retroativa com um pequeno número de chaves usadas só por nerds de segurança. Claro, se houver uma forma de manter essa UX sem chaves residentes, tudo bem

  • Em geral, penso parecido. A ideia para a qual todos parecem estar convergindo hoje é ter um cofre de segurança criptografado local e confiável, e ter de comprovar sua identidade a esse sistema. Pode ser uma senha, pode ser uma chave
    É mais fácil confiar que o gerenciador de senhas escolhido é mais seguro do que assumir que todos os serviços do mundo em que se cria uma conta são seguros ou impossíveis de sofrer phishing. Então, quando você chega ao ponto de usar passkeys, muitas vezes já está em um contexto mais seguro, no qual estabeleceu sua identidade para o sistema operacional ou para um gerenciador de senhas que detém as passkeys. Além disso, lugares que até agora, ou até recentemente, não ofereciam suporte a chaves de hardware provavelmente também não ofereceriam em um futuro próximo. Já uma solução de passkeys é muito mais fácil, pois o custo de adoção é basicamente suporte de software, então a relação custo-benefício tende a ser alta. Claro, isso se aplica principalmente a sites, e passkeys são mais próximas de “chaves SSH padronizadas” para sites. Chaves de hardware parecem mais úteis como um segundo fator que de fato abre o cofre onde estão as passkeys, e nesse caso uma senha também pode ser necessária. Acho que as chaves de hardware ainda têm alguma vida pela frente. Testando em GitHub, Gmail etc. como método padrão, o fluxo de login com passkey é realmente muito bom
  • Gerenciadores de senhas já tornaram senhas obsoletas. Tirando uma única senha mestra, não sei nenhuma das minhas senhas. Passkeys são uma solução excessivamente complexa de que não precisamos necessariamente
    O navegador só precisaria ter uma API HATEOAS simples à qual os gerenciadores de senhas pudessem se conectar, e os apps web exporiam HTML que acionasse o navegador. Então o gerenciador de senhas decidiria como autenticar o usuário, ou seja, da forma que o usuário quisesse, e injetaria automaticamente o segredo daquele site, fazendo o usuário entrar automaticamente. Se algo desse errado, bastaria usar a redefinição por e-mail. Entendo que, do ponto de vista de sites que querem “segurança super sofisticada”, eles queiram algo mais complexo. Mas o usuário deveria poder ativar seletivamente um nível de segurança mais alto. Por exemplo, para a maioria dos sites, supondo que o gerenciador de senhas use uma senha aleatória, um hash de senha simples é suficiente. Qualquer site consegue implementar, qualquer gerenciador de senhas consegue implementar, e é melhor do que o uso atual de senhas por 99% dos usuários comuns. Isso poderia ser o método de autenticação padrão. Depois, se quiser TOTP, OIDC, criptografia de chave pública etc., o servidor anuncia e o cliente participa seletivamente para continuar a autenticação. Nem todos os sites e nem todos os usuários precisam usar o método mais seguro. Primeiro, é preciso facilitar elevar a linha de base da segurança, e deixar que proteções mais fortes sejam escolhidas aos poucos
  • Ao fazer autenticação sem senha (FIDO2) com uma Yubikey, ela pede um PIN antes de solicitar que você toque no dispositivo. Se você errar o PIN muitas vezes, a Yubikey bloqueia e passa a exigir a redefinição do dispositivo, o que invalida todos os registros existentes que usavam aquela chave para autenticação
    Mesmo que alguém roube meu token de hardware, isso não parece um grande problema. https://support.yubico.com/hc/en-us/articles/4402836718866-U...
  • Pensando bem, o problema central pode ser descrito como “autenticar um ser biológico em um sistema eletrônico”
    Quando se usa uma senha, a interface de autenticação é o teclado, e não há garantia real de que a pessoa digitando a senha seja quem afirma ser. Senhas dependem de conhecimento facilmente transferível, portanto podem ser extraídas de várias formas. É muito melhor deslocar a interface de autenticação para uma relação dispositivo a dispositivo. Em vez de presumir que um conhecimento facilmente transferível não foi transferido, presume-se que o ser biológico consegue cuidar do dispositivo de autenticação, e as pessoas em geral são bem capazes disso. Também é possível aumentar o número de canais de autenticação para torná-la mais robusta, e limitar a autenticação entre o ser biológico e o dispositivo usado para autenticação em sistemas remotos, como no Face ID. No fundo, parece natural assumir que um dispositivo, como um celular ou uma chave, é a própria pessoa. Em casa, compartilhamos não só a senha da Netflix, mas também um cartão de crédito. Por motivos práticos, deixamos um cartão de crédito junto com uma chave reserva, e qualquer um pode pegá-lo para comprar algo necessário para a casa. Confiamos que todos usarão o cartão corretamente, e todos sabem o PIN, embora quase nunca seja necessário porque pagamentos por aproximação são comuns. Isso é muito mais natural do que controlar despesas e acertar contas depois. Provavelmente é ilegal, e o banco cancelaria o cartão se soubesse, mas enfim. Sistemas de TI precisam urgentemente se aproximar do comportamento humano funcionando de modo semelhante ao mundo real. Como estou envolvido com sistemas de TI, na maior parte das vezes aguento, mas pessoas menos familiarizadas com tecnologia têm dificuldade até com problemas cotidianos como qual é a senha do iPhone, qual é a senha do iCloud, qual é a senha do Gmail, ou por que precisam digitar um código no WhatsApp. Para falar a verdade, nem eu entendi o Mastodon. Acho que eu estaria indefeso contra phishing no Mastodon, e provavelmente digitaria qualquer coisa que a tela mandasse digitar
  • Não é correto dizer que passkeys são substitutas de senhas

As passkeys, como o nome sugere, parasitam o padrão FIDO2 U2F, que foi desenvolvido como um segundo fator. Chaves residentes são para autenticação de dois fatores no próprio dispositivo com PIN, e são um substituto funcional para smartcards. Alguém, provavelmente a Apple, parece ter achado que apenas WebAuthn era suficiente para ser o único fator de autenticação. Sem chave residente, sem vínculo de hardware, com as chaves se movendo via iCloud, mas supostamente protegidas no dispositivo por TouchID/FaceID. E isso foi comercializado com a marca passkey. A autenticação de dois fatores em si não é o objetivo. O objetivo é autenticação de usuário segura contra phishing, força bruta e ataques de credential stuffing, sem ser tão difícil de implementar quanto smartcards. O FIDO2 consegue fazer isso. O problema das implementações da Apple, Google e Microsoft não é que a segurança em nível de protocolo entre o site autenticador e o dispositivo do usuário seja baixa. O protocolo é o mesmo. O problema é que agora o site precisa confiar na conta pessoal de plataforma do usuário, acreditar que o usuário a configurou corretamente e que a plataforma continuará sempre se comportando corretamente no futuro para lidar adequadamente com ataques à conta pessoal do usuário.

• Para acrescentar contexto: administro uma empresa de autenticação sem senha apoiada pela YC e venho implantando isso em grandes organizações. Parece claro que as passkeys serão a resposta para a autenticação sem senha no mercado consumidor, mas isso ainda não parece se refletir nos ambientes corporativos
  Passkeys são ótimas para consumidores. Isso porque elas têm como objetivo permitir que o próprio usuário tenha acesso de emergência, fazendo backup das credenciais em outros dispositivos por meio de recursos como backup padrão do iCloud ou AirDrop. Tecnicamente, os dispositivos que recebem essas credenciais compartilhadas não conseguem fornecer atestado. Atestado é a “prova” de que o par de chaves foi gerado em um dispositivo específico, como uma Yubikey ou um dispositivo Apple. Fabricantes como a Yubico embarcam pares de chaves e certificados não extraíveis nas chaves quando as enviam, e como não há interface externa para acessar esse par de chaves, um administrador pode ter alta confiança de que aquilo é uma Yubikey genuína. Quando não há atestado e a chave pode ser compartilhada, dá para ver onde o problema começa. Empresas não querem assumir o risco de que credenciais que podem ser enviadas por AirDrop exponham o acesso a contas privilegiadas de funcionários. Com uma Yubikey, o risco de roubo digital é praticamente inexistente. No fim, passkeys também não podem ser usadas para desbloquear dispositivos ou servidores. O FIDO2 e, mais importante, os desenvolvedores de sistemas operacionais ainda têm um longo caminho pela frente para acabar de vez com as senhas. Hoje, na maior parte do mercado corporativo, a Yubikey preenche essa lacuna, e algumas empresas já gastaram milhões de dólares em hardware. No estado atual, passkeys serão difíceis de vender

  • Passkey não é um termo técnico, mas um termo de experiência. Por isso, ele meio que desmorona quando usado em argumentação técnica
    A Apple oferece suporte a passkeys, assim como Android e Chrome, Microsoft e Yubikey. Mas recursos e restrições como o procedimento de autenticação para verificação do usuário e a possibilidade de clonagem podem variar muito. Órgãos governamentais podem oferecer suporte a passkeys, mas permitir seu uso apenas quando fornecidas por um autenticador com certificação FIPS que atenda aos requisitos AAL2. Pelo menos por enquanto, isso não virá da Apple ou do Google. Empresas podem optar por oferecer suporte a passkeys criadas por software e configurações fornecidos por produtos gerenciados via MDM, e a Apple anunciou suporte beta para isso. Dito isso, serviços de governo para cidadãos podem sofrer bastante se tentarem impor um autenticador de hardware específico. É difícil convencer cidadãos a comprar um hardware de mais de US$ 80, e como as tecnologias web foram criadas em torno da escolha do usuário, é improvável que a API WebAuthn e a experiência do usuário sejam otimizadas para ajudar a restringir essa escolha
  • O que acontece se Google ou Apple bloquearem uma conta por engano, por motivos absurdos como prevenção de bots ou detecção de fraude?
  • Yubikeys 5 podem ser usadas como passkeys

• Do ponto de vista de segurança, acho que esta é uma solução realmente péssima
  É uma estrutura dos sonhos para governos e empresas como Apple e Google controlarem a vida digital. Quando se usa senha, ela é quase uma espécie de mecanismo sem estado: mesmo que você atravesse uma fronteira com uma conta de e-mail pessoal ou qualquer outra conta, ninguém consegue saber que você possui essa conta, e é difícil forçá-lo a entregar o acesso, extrair do hardware os elementos de acesso ou bloqueá-lo porque você perdeu acesso a um dispositivo. Mesmo que chaves mestras e afins sejam armazenadas em um TPM ou elemento seguro, alguns governos conseguem acessá-las; é apenas uma questão de anos e poder computacional. Na maioria dos casos, isso por si só também se torna prova de que você possui credenciais de uma conta específica. Fabricantes de dispositivos ou sistemas operacionais podem ser facilmente obrigados pelas autoridades a fornecer acesso à área segura, voluntariamente ou não