Login resistente a phishing com WebAuthn e passkeys

O que é

A Web Authentication API permite que uma aplicação web crie e use credenciais de chave pública. No registro, navigator.credentials.create() pede a um autenticador (o da própria plataforma, desbloqueado por biometria ou PIN, ou uma chave de segurança externa) que gere um par de chaves; o servidor, chamado de relying party (parte confiável), armazena a chave pública junto com a conta. No login, navigator.credentials.get() envia um desafio (challenge) gerado pelo servidor; após o consentimento do usuário, o autenticador o assina com a chave privada e o servidor verifica a assinatura com a chave pública armazenada. A especificação vincula cada credencial a um identificador da parte confiável (RP ID), uma string de domínio que por padrão corresponde ao domínio efetivo da origem e só pode ser substituída por um sufixo desse domínio que seja um domínio registrável. Uma credencial só pode ser usada com a mesma entidade, identificada pelo RP ID, com a qual foi registrada, e os dados do cliente cobertos pela assinatura incluem a origem. Passkeys são credenciais WebAuthn detectáveis (discoverable): o autenticador guarda a chave privada e o user handle, de modo que não é preciso digitar um nome de usuário antes. Em muitas implementações, elas também são sincronizadas entre os dispositivos do usuário pelo fornecedor da plataforma. A MDN observa que, na web, as passkeys são implementadas com essa API.

Por que importa

Senhas e códigos de uso único podem ser digitados em uma página de phishing e repassados. Resumo da MDN sobre a defesa: um atacante que cria um site de login falso não consegue entrar como o usuário, porque a assinatura muda conforme a origem do site. O servidor não guarda nenhum segredo que possa ser reutilizado, então o vazamento da tabela de credenciais expõe apenas chaves públicas.

Como aplicar

• Use uma biblioteca de servidor mantida ativamente para as cerimônias de registro e de asserção; verifique o challenge, a origem, o hash do RP ID e a assinatura, e confira o contador de assinaturas quando o autenticador fornecer um.
• Escolha o RP ID com critério (o domínio registrável, se vários subdomínios compartilham contas) e mantenha-o estável; alterá-lo invalida todas as credenciais.
• Permita várias credenciais por conta e projete a recuperação de conta de modo que ela não seja mais fraca do que a passkey que substitui.
• Para login sem senha, solicite credenciais detectáveis e verificação do usuário; se o modelo de conta ainda não estiver pronto, ofereça primeiro as passkeys como segundo fator.
• Armazene o id da credencial, a chave pública, o contador de assinaturas e os transports; a chave privada nunca chega ao servidor.

Armadilhas

Quando o fator principal passa a resistir a phishing, os fluxos de recuperação (links de redefinição por e-mail, atendimento de suporte) tornam-se o alvo do phishing. A attestation é opcional, e a MDN recomenda que as partes confiáveis não mantenham listas de autenticadores permitidos. Passkeys sincronizadas transferem a confiança para a conta de plataforma do usuário; credenciais vinculadas ao dispositivo em chaves de segurança não são sincronizadas e exigem uma segunda credencial registrada. Os diálogos de navegadores e plataformas variam; teste nos dispositivos que seus usuários têm.