FIDO2 Desvendado: WebAuthn, Chaves de Acesso e Segurança (PT-BR)

O FIDO2 compreende dois padrões de autenticação de chave pública: a API de Autenticação Web (WebAuthn) do World Wide Web Consortium e o Protocolo Cliente para Autenticador (CTAP) da FIDO Alliance. Juntos, eles permitem que uma parte confiável registre e use uma credencial criptográfica sem armazenar um segredo compartilhado reutilizável como uma senha.

O FIDO2 pode fornecer autenticação resistente a phishing e a replay quando implementado e validado corretamente. Ele não prova a identidade legal de uma pessoa, não decide quem deve ter permissão para se registrar, não protege uma sessão de servidor comprometida, nem repara um processo fraco de recuperação de conta. Esses são controles adjacentes que devem ser projetados em torno da cerimônia de autenticação.

Principais pontos

• FIDO2 é WebAuthn mais CTAP. WebAuthn conecta um site ou aplicativo ao cliente; CTAP conecta a plataforma cliente a um autenticador itinerante.
• A chave privada permanece com o autenticador. A parte confiável armazena uma chave pública e verifica assinaturas em desafios recentes e contexto delimitado.
• A vinculação de domínio cria resistência a phishing. Uma credencial registrada para um identificador de parte confiável não pode simplesmente ser repetida para um domínio não relacionado de um invasor.
• Chaves de acesso são credenciais FIDO. Elas podem ser vinculadas a dispositivos ou sincronizadas entre dispositivos de um provedor, criando diferentes compensações de garantia, recuperação e portabilidade.
• A recuperação faz parte do modelo de segurança. Um login FIDO2 forte pode ser ignorado se caminhos de e-mail, suporte ou recuperação de identidade puderem substituir a credencial por evidências mais fracas.

O que é FIDO2?

A visão geral das especificações da FIDO Alliance define FIDO2 como a combinação da especificação W3C WebAuthn e dos Protocolos Cliente para Autenticador FIDO. Os padrões dividem o sistema em funções cooperativas:

• Parte confiável: o site ou serviço que registra credenciais e verifica asserções de autenticação.
• Cliente: geralmente o componente do navegador ou sistema operacional que implementa WebAuthn e intermedia a cerimônia.
• Autenticador: um componente de plataforma ou dispositivo externo que cria e usa a chave da credencial.
• Usuário: a pessoa que consente com o registro ou autenticação e pode verificar localmente com um PIN, senha ou biometria.

A especificação W3C WebAuthn Nível 3 define uma API web para criar e usar credenciais de chave pública delimitadas a uma parte confiável. Os scripts nunca recebem a chave da credencial privada. Eles recebem dados estruturados e prova criptográfica produzidos através do autenticador e do cliente.

FIDO2, WebAuthn, CTAP, U2F e chaves de acesso comparados

Termo	Significado prático	Principal limite
FIDO2	Os padrões WebAuthn e CTAP usados em conjunto	Família completa de padrões, não uma única chamada de API
WebAuthn	API do navegador ou cliente e modelo de dados da parte confiável para credenciais de chave pública	Conecta a parte confiável ao cliente
CTAP2	Protocolo entre a plataforma cliente e um autenticador itinerante	Transporta comunicação de autenticador externo por USB, NFC e BLE, por exemplo
U2F / CTAP1	Protocolo FIDO anterior comumente associado a chaves de segurança de segundo fator	Mais limitado do que as capacidades modernas do FIDO2
Chave de acesso	Uma credencial FIDO detectável projetada para login sem senha	Pode ser sincronizada ou vinculada ao dispositivo
Chave de segurança	Um autenticador de hardware itinerante conectado por USB, NFC ou outro transporte suportado	Uma forma possível de autenticador
Autenticador de plataforma	Autenticador integrado a um dispositivo ou sistema operacional	Geralmente ativado com PIN local ou biometria

“Sem senha” descreve a jornada do usuário, não todas as implantações possíveis. Um serviço pode usar WebAuthn como segundo fator após uma senha, como credencial multifator primária ou ao lado de outros autenticadores. A parte confiável deve decidir quais características e sinalizadores de credencial atendem à garantia da ação protegida.

Como funciona o registro FIDO2

O registro, também chamado de criação de credencial, vincula uma nova credencial de chave pública a uma conta na parte confiável.

1. O servidor cria opções de registro

A parte confiável gera um desafio novo e imprevisível e envia opções de criação de credencial de chave pública ao cliente. As opções identificam a parte confiável, a conta de usuário, os algoritmos aceitos, as preferências do autenticador, a preferência de atestado e os identificadores de credenciais existentes excluídos, quando relevantes.

Os desafios devem ser de uso único, de curta duração, vinculados à sessão e ao usuário corretos, e armazenados ou verificáveis pelo servidor. Um desafio gerado apenas no navegador não pode proteger a cerimônia do servidor.

2. O cliente invoca WebAuthn

O aplicativo chama navigator.credentials.create() com as opções de chave pública. O navegador verifica a origem e o contexto de segurança, então pede a um autenticador disponível para criar uma credencial.

3. O autenticador obtém o consentimento do usuário

O autenticador requer a presença do usuário e, se solicitado e suportado, a verificação do usuário. A presença do usuário pode ser um toque ou ação explícita. A verificação do usuário significa que o autenticador verifica localmente o usuário por meio de um PIN, segredo do dispositivo, biometria ou outro método suportado.

Uma biometria local normalmente desbloqueia o uso da credencial; o modelo biométrico não é enviado ao site como segredo de autenticação.

4. O autenticador cria um par de chaves

O autenticador cria um par de chaves de credencial delimitado à parte confiável. A chave privada permanece protegida pelo autenticador ou por sua estrutura de sincronização. A credencial resultante contém a chave pública, o identificador da credencial, os dados do autenticador, os dados do cliente e as informações de atestado de acordo com o formato selecionado.

5. O servidor valida e armazena a credencial

A parte confiável valida a cerimônia antes de armazenar qualquer coisa. As verificações incluem:

• desafio esperado;
• origem esperada;
• hash correto do identificador da parte confiável;
• estado cross-origin esperado e topOrigin quando a cerimônia está incorporada;
• sinalizadores de presença do usuário e verificação do usuário de acordo com a política;
• algoritmo e parâmetros de chave aceitos;
• estrutura de atestado e política de confiança se o atestado for solicitado;
• singularidade e associação com a conta de usuário correta.

O servidor armazena o identificador da credencial, a chave pública, a vinculação da conta, o contador de assinaturas ou o estado aplicável, os transportes ou metadados quando úteis e as informações do ciclo de vida da credencial. Ele nunca precisa da chave privada.

Como funciona a autenticação FIDO2

A autenticação prova o controle de uma credencial previamente registrada.

1. O servidor cria opções de solicitação

A parte confiável gera um novo desafio e envia opções de asserção. Ela pode incluir uma lista de permissões de identificadores de credencial ou usar credenciais detectáveis para que o autenticador possa identificar a conta.

2. O cliente solicita uma asserção

O aplicativo chama navigator.credentials.get(). O navegador e o autenticador selecionam uma credencial adequada e obtêm a presença do usuário ou a verificação local do usuário necessária.

3. O autenticador assina os dados da cerimônia

O autenticador assina o contexto do desafio recente e os dados do autenticador usando a chave privada da credencial. Como a credencial é delimitada à parte confiável, uma origem de phishing não relacionada não pode pedir ao autenticador para produzir uma asserção válida para o serviço real.

4. O servidor verifica a asserção

A parte confiável verifica o desafio esperado, a origem, o hash da parte confiável, a assinatura com a chave pública armazenada, os sinalizadores necessários, a credencial permitida, a vinculação do usuário e o contador ou estado de backup relevante. Somente então ele deve criar ou elevar uma sessão de aplicativo.

Cada asserção prova o controle em um momento. A criação de sessão, proteção de token, reautenticação, autorização de transação, logout e revogação permanecem responsabilidades separadas do aplicativo.

Por que o FIDO2 é resistente a phishing

Senhas e códigos de uso único podem ser inseridos em um site impostor, que pode retransmiti-los para o serviço real. O FIDO2 usa uma credencial delimitada à parte confiável e vincula criptograficamente a asserção ao contexto esperado do verificador.

Os requisitos do autenticador NIST SP 800-63B-4 descrevem o WebAuthn como resistente a phishing através da vinculação do nome do verificador. A saída do autenticador é vinculada ao nome de domínio autenticado em vez de depender do usuário perceber uma página enganosa.

A resistência a phishing tem limites:

• Não impede malware ou um invasor que já controla uma sessão autenticada.
• Não impede que um usuário aprove uma transação maliciosa dentro do serviço genuíno.
• Não protege um caminho de recuperação de conta que possa substituir a credencial.
• Não prova que a pessoa que controla o autenticador é a pessoa real que uma organização pretendia registrar.

Resistência a replay e tratamento de desafios

Uma asserção gravada não deve funcionar em uma cerimônia posterior porque cada solicitação usa um desafio recente. O NIST descreve autenticadores criptográficos que incorporam nonces ou desafios como resistentes a replay.

Erros de implementação podem remover essa propriedade. Falhas comuns incluem desafios previsíveis, reutilização de desafios, aceitação de um desafio para a conta errada, não aplicação de expiração ou validação apenas da assinatura, ignorando a origem e o contexto da parte confiável.

O servidor deve marcar um desafio consumido atomicamente. Se solicitações paralelas competirem, apenas uma cerimônia bem-sucedida deve ser capaz de usar esse desafio.

Presença do usuário e verificação do usuário

WebAuthn distingue:

• Presença do usuário (UP): o usuário realizou uma interação indicando participação.
• Verificação do usuário (UV): o autenticador verificou localmente o usuário por meio de um fator de ativação, como um PIN ou biometria.

A presença por si só não é autenticação multifator. Um serviço que protege uma ação de maior risco pode exigir o sinalizador UV e rejeitar asserções que mostrem apenas presença. Os requisitos devem indicar os valores esperados dos sinalizadores, em vez de depender de um rótulo de interface como “Usar Face ID”.

A qualidade da verificação local também varia por autenticador. A parte confiável pode ter visibilidade limitada sobre a implementação exata de biometria ou PIN para autenticadores fornecidos pelo usuário, portanto, a política deve ser proporcional à transação e à população de implantação.

Autenticadores de plataforma, itinerantes e entre dispositivos

Autenticadores de plataforma

Estes são integrados a um telefone, laptop ou sistema operacional. Eles podem fornecer uma jornada curta usando o método de desbloqueio local do dispositivo. A desvantagem é a dependência da recuperação da conta da plataforma, da segurança do dispositivo e do comportamento de sincronização.

Autenticadores itinerantes

Chaves de segurança externas podem ser transportadas entre dispositivos e conectadas por meio de transportes suportados. São úteis para casos de uso de força de trabalho, administrativos ou de alta garantia, especialmente quando a não exportabilidade de credenciais e a emissão gerenciada são importantes.

Autenticação entre dispositivos

Fluxos híbridos podem usar um telefone próximo para autenticar uma sessão em outro dispositivo. Os mecanismos de transferência e proximidade melhoram a usabilidade, mas adicionam detalhes de interface do usuário e modelo de ameaça que devem ser testados em vez de serem tratados como idênticos à autenticação no mesmo dispositivo.

Suporte a múltiplas credenciais por conta. Os usuários substituem telefones, perdem chaves de segurança, usam dispositivos de trabalho e pessoais e precisam de uma maneira segura de nomear, inspecionar e remover credenciais.

Chaves de acesso vinculadas a dispositivos e sincronizadas

Uma chave de acesso é uma credencial FIDO projetada para login sem senha. As chaves de acesso podem ser:

• Vinculadas a dispositivos: a chave privada da credencial permanece ligada a um autenticador ou dispositivo gerenciado.
• Sincronizadas: o material da credencial é criptografado e sincronizado através da estrutura de um provedor para uso em dispositivos elegíveis.

As chaves de acesso sincronizadas melhoram a disponibilidade e a recuperação, enquanto as credenciais vinculadas a dispositivos podem fornecer uma não exportabilidade mais forte. A orientação do NIST SP 800-63B-4 para autenticadores sincronizáveis permite autenticadores sincronizáveis em contextos até o Nível de Garantia de Autenticação 2 quando seus requisitos são atendidos, mas a sincronização entra em conflito com a não exportabilidade exigida no Nível 3.

Não infira garantia da palavra “chave de acesso”. Avalie se as credenciais são copiadas, elegíveis para backup, compartilhadas, gerenciadas, vinculadas a dispositivos, atestadas e ativadas com verificação de usuário de acordo com a política da parte confiável.

Atestado e confiança do autenticador

O atestado pode fornecer evidências sobre a proveniência ou propriedades de um autenticador no registro. Não é o mesmo que a assinatura de autenticação e não identifica o usuário humano.

Serviços ao consumidor geralmente minimizam a coleta de atestados para privacidade e compatibilidade de ecossistema. Implementações gerenciadas de força de trabalho podem exigir modelos ou certificações de autenticador específicos. A decisão deve responder a uma questão do modelo de ameaça, em vez de coletar evidências de identificação de dispositivo por padrão.

Se o atestado for usado:

• defina formatos aceitos e âncoras de confiança;
• valide corretamente os caminhos e declarações de certificados;
• especifique o tratamento de atualização e revogação de metadados;
• planeje para autenticadores sem atestado confiável;
• documente as consequências de privacidade e retenção;
• teste a substituição quando um modelo aceito muda de status.

FIDO2 não substitui a prova de identidade

FIDO2 prova o controle de uma credencial registrada em uma parte confiável. Não estabelece o nome legal, idade, endereço, status regulatório ou singularidade no mundo real da pessoa que a registra.

Essa distinção cria três padrões comuns:

1. Registro pseudônimo: o serviço precisa de uma conta segura, mas não de uma identidade real verificada.
2. Registro vinculado à identidade: a prova de identidade ocorre primeiro, então uma credencial FIDO é vinculada à conta verificada.
3. Step-up ou recuperação: o serviço verifica novamente a identidade ou usa outras evidências fortes antes de permitir que um autenticador perdido seja substituído.

A vinculação deve ser explícita. Registre qual conta e estado de prova existiam quando a credencial foi adicionada, qual sessão a autorizou e se o risco posterior deve acionar reautenticação ou atualização de identidade.

Recuperação de conta e ciclo de vida da credencial

A recuperação é onde muitas implantações resistentes a phishing se degradam. Se um usuário puder substituir todas as credenciais FIDO usando um link enviado por e-mail ou perguntas de suporte fracas, um invasor visará esse caminho.

Um ciclo de vida completo abrange:

• adicionar um segundo autenticador;
• nomear e visualizar credenciais registradas;
• perda de dispositivo e suspeita de comprometimento;
• revogar uma credencial sem destruir a conta;
• recuperar com códigos, outro autenticador, suporte gerenciado ou prova de identidade;
• notificar o usuário por um canal independente;
• atrasar ou limitar ações de alto risco após a recuperação;
• registrar quem alterou o conjunto de credenciais e por quê;
• encerrar sessões criadas antes que o comprometimento fosse relatado.

A garantia de recuperação deve corresponder à consequência da substituição do autenticador. Uma conta comunitária de baixo risco e um administrador que pode movimentar fundos não precisam do mesmo caminho.

Como avaliar uma implantação FIDO2

Validação do protocolo

Teste a geração e expiração de desafios, a validação exata da origem, as regras de identificador da parte confiável, a verificação de assinatura, os algoritmos suportados, a política de UP e UV, a associação de credenciais, os contadores, os sinalizadores de backup e o tratamento de erros. Prefira uma biblioteca de servidor mantida em vez de análise binária escrita à mão, enquanto ainda entende o que ela valida.

Cobertura do autenticador

Teste autenticadores de plataforma e itinerantes em navegadores, sistemas operacionais, dispositivos, transportes, políticas empresariais e configurações de acessibilidade suportados. Inclua criação de credenciais, login, interface de usuário condicional, uso entre dispositivos e substituição de dispositivos.

Segurança de conta e sessão

Revise quem pode adicionar uma credencial, se a autenticação recente é necessária, como as sessões são elevadas, quando a reautenticação ocorre e como as alterações de credenciais afetam as sessões existentes.

Recuperação e suporte

Simule perda, dispositivos roubados, e-mail comprometido, troca de SIM, representação de suporte e acesso malicioso em casa ou no trabalho. Meça tanto a resistência do invasor quanto a conclusão do usuário genuíno.

Privacidade e observabilidade

Minimize o atestado e os dados do dispositivo para o que a política precisa. Evite usar identificadores de credenciais estáveis entre as partes confiáveis; o escopo do WebAuthn é projetado para evitar isso. Registre os motivos e os resultados da cerimônia sem vazar dados confidenciais do cliente.

Erros comuns de implementação do FIDO2

Verificar a assinatura, mas não o contexto

Uma assinatura válida é insuficiente se o servidor falhar em verificar o desafio, a origem, o identificador da parte confiável, os sinalizadores e a vinculação da conta exatamente.

Chamar toda chave de acesso de multifator

O servidor deve verificar se a verificação do usuário ocorreu e se as características da credencial atendem à política. A presença do usuário por si só não é o mesmo que a verificação local do usuário.

Permitir a adição silenciosa de credenciais

Adicionar um novo autenticador altera a segurança da conta. Exija uma autenticação recente apropriada ou cerimônia de recuperação, notifique o usuário e registre o evento.

Suportar apenas uma credencial

Contas com uma credencial criam uma recuperação frágil e incentivam alternativas mais fracas. Permita múltiplos autenticadores com gerenciamento e revogação claros.

Deixar a senha como um fallback igual

Se uma senha sempre puder ignorar o caminho FIDO, a resistência a phishing pode existir apenas no botão preferencial. Restrinja ou remova caminhos mais fracos de acordo com o risco e o estágio de migração.

Ignorar sessões de servidor

FIDO2 autentica a cerimônia de login. Proteja cookies e tokens, gire as sessões após a autenticação, exija step-up para ações sensíveis e revogue sessões comprometidas.

Uma lista de verificação de implantação

Antes do lançamento, confirme que:

• os desafios são imprevisíveis, de uso único, de curta duração e vinculados à sessão correta;
• a origem, o identificador da parte confiável, a assinatura, o algoritmo, os sinalizadores e a propriedade da credencial são validados;
• os requisitos de UP e UV são explícitos para cada ação protegida;
• os casos de plataforma, itinerantes, sincronizados, vinculados a dispositivos e entre dispositivos são testados conforme suportados;
• os usuários podem registrar múltiplas credenciais e nomeá-las, inspecioná-las e revogá-las com segurança;
• a adição e recuperação de credenciais exigem garantia proporcional e geram notificações;
• a coleta de atestados tem uma política definida de confiança, privacidade e metadados;
• as senhas, códigos de uso único, suporte e alternativas de recuperação de identidade são modelados em relação a ameaças;
• as sessões autenticadas e a autorização de transações são protegidas separadamente;
• as bibliotecas de protocolo, o suporte do navegador, as depreciações e os eventos de segurança têm proprietários.

Onde a Didit se encaixa ao lado do FIDO2

FIDO2 lida com a autenticação depois que uma credencial foi registrada. A Didit pode apoiar a decisão de identidade adjacente através de Verificação de Identidade, Detecção de Prova de Vida e Autenticação Biométrica. O preço publicado da Autenticação Biométrica é de US$ 0,10 por verificação.

As equipes podem revisar as taxas atuais dos módulos na página de preços. Estes produtos não devem ser assumidos como implementando FIDO2 a partir dessa descrição: o ponto arquitetônico é que a prova de identidade, verificações biométricas, autenticação de credenciais FIDO, recuperação de conta e autorização de aplicativos são decisões de confiança diferentes.

Perguntas frequentes

O que significa FIDO2?

FIDO significa Fast Identity Online. FIDO2 é a família de padrões que combina W3C WebAuthn com FIDO Alliance CTAP para autenticação de chave pública.

FIDO2 é o mesmo que WebAuthn?

Não. WebAuthn define a API da parte confiável e do cliente e o modelo de dados. FIDO2 inclui WebAuthn mais CTAP, que conecta a plataforma cliente com autenticadores itinerantes.

Chaves de acesso são credenciais FIDO2?

Sim. Chaves de acesso são credenciais FIDO detectáveis projetadas para login sem senha. Elas podem ser sincronizadas entre dispositivos elegíveis ou permanecerem vinculadas a dispositivos.

FIDO2 é resistente a phishing?

A autenticação FIDO2 devidamente validada é resistente a phishing porque a credencial é delimitada à parte confiável e a asserção é vinculada a esse contexto de verificador. Uma recuperação fraca ou uma sessão já comprometida ainda podem ignorar a proteção pretendida.

FIDO2 usa biometria?

Pode usar uma biometria local para ativar um autenticador e definir a verificação do usuário. A parte confiável normalmente recebe o resultado e a asserção criptográfica, não o modelo biométrico.

FIDO2 verifica a identidade de uma pessoa?

Não. Ele verifica o controle de uma credencial registrada. A prova de identidade no mundo real é uma decisão separada de registro ou recuperação quando o serviço a exige.

O que acontece quando um usuário perde todos os autenticadores?

O serviço precisa de uma política de recuperação proporcional ao risco da conta. As opções podem incluir outro autenticador registrado, códigos de recuperação, recuperação administrativa gerenciada ou prova de identidade renovada, com notificação e restrições pós-recuperação.

Referências principais

• Especificações de Autenticação de Usuário da FIDO Alliance
• Snapshot da Recomendação Candidata W3C Web Authentication Nível 3
• Padrão Proposto FIDO Alliance CTAP 2.3
• NIST SP 800-63B-4: Autenticação e Gerenciamento de Autenticador
• Requisitos do autenticador NIST SP 800-63B-4

FIDO2 substitui segredos de verificador reutilizáveis por credenciais de chave pública delimitadas e cerimônias criptográficas recentes. Seu valor sobrevive apenas quando a parte confiável valida o contexto completo, gerencia o ciclo de vida da credencial, protege sessões e ações sensíveis, e dá à recuperação a mesma atenção de segurança que ao login.