FIDO2 Decifrado: WebAuthn, Passkeys e Segurança (PT-PT)

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, permitem que uma parte de confiança registe e utilize uma credencial criptográfica sem armazenar um segredo partilhado reutilizável como uma palavra-passe.

O FIDO2 pode fornecer autenticação resistente a phishing e a ataques de repetição quando implementado e validado corretamente. Não prova a identidade legal de uma pessoa, não decide quem deve ser autorizado a registar-se, não protege uma sessão de servidor comprometida nem repara um processo de recuperação de conta fraco. Estes são controlos adjacentes que devem ser concebidos em torno da cerimónia de autenticação.

Principais conclusões

• FIDO2 é WebAuthn mais CTAP. WebAuthn conecta um website ou aplicação ao cliente; CTAP conecta a plataforma cliente a um autenticador itinerante.
• A chave privada permanece com o autenticador. A parte de confiança armazena uma chave pública e verifica assinaturas sobre novos desafios e contexto delimitado.
• A vinculação de domínio cria resistência a phishing. Uma credencial registada para um identificador de parte de confiança não pode ser simplesmente reproduzida para um domínio não relacionado de um atacante.
• Passkeys são credenciais FIDO. Podem ser vinculadas a um dispositivo ou sincronizadas entre os dispositivos de um fornecedor, criando diferentes compromissos de garantia, recuperação e portabilidade.
• A recuperação faz parte do modelo de segurança. Um login FIDO2 forte pode ser contornado se os caminhos de email, 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 cooperantes:

• Parte de confiança: o website ou serviço que regista credenciais e verifica asserções de autenticação.
• Cliente: geralmente o navegador ou componente do sistema operativo que implementa WebAuthn e intermedeia a cerimónia.
• Autenticador: um componente de plataforma ou dispositivo externo que cria e usa a chave de credencial.
• Utilizador: a pessoa que consente o registo ou autenticação e pode verificar localmente com um PIN, palavra-passe ou dados biométricos.

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 de confiança. Os scripts nunca recebem a chave de credencial privada. Recebem dados estruturados e prova criptográfica produzidos através do autenticador e cliente.

FIDO2, WebAuthn, CTAP, U2F e passkeys comparados

Termo	Significado prático	Limite principal
FIDO2	Os padrões WebAuthn e CTAP usados em conjunto	Família completa de padrões, não uma chamada de API
WebAuthn	API do navegador ou cliente e modelo de dados da parte de confiança para credenciais de chave pública	Conecta a parte de confiança ao cliente
CTAP2	Protocolo entre a plataforma cliente e um autenticador itinerante	Transporta a comunicação do autenticador externo por transportes como USB, NFC e BLE
U2F / CTAP1	Protocolo FIDO anterior comumente associado a chaves de segurança de segundo fator	Mais limitado do que as capacidades modernas do FIDO2
Passkey	Uma credencial FIDO detetável projetada para login sem palavra-passe	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 num dispositivo ou sistema operativo	Frequentemente ativado com PIN local ou dados biométricos

“Sem palavra-passe” descreve a jornada do utilizador, não todas as implementações possíveis. Um serviço pode usar WebAuthn como um segundo fator após uma palavra-passe, como uma credencial multifator primária ou juntamente com outros autenticadores. A parte de confiança deve decidir quais características e sinalizadores de credencial satisfazem a garantia da ação protegida.

Como funciona o registo FIDO2

O registo, também chamado de criação de credenciais, vincula uma nova credencial de chave pública a uma conta na parte de confiança.

1. O servidor cria opções de registo

A parte de confiança gera um desafio novo e imprevisível e envia opções de criação de credenciais de chave pública ao cliente. As opções identificam a parte de confiança, a conta de utilizador, algoritmos aceites, preferências do autenticador, preferência de atestação e identificadores de credenciais existentes excluídos, quando relevante.

Os desafios devem ser de uso único, de curta duração, vinculados à sessão e ao utilizador 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

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

3. O autenticador obtém o consentimento do utilizador

O autenticador requer a presença do utilizador e, se solicitado e suportado, a verificação do utilizador. A presença do utilizador pode ser um toque ou uma ação explícita. A verificação do utilizador significa que o autenticador verifica localmente o utilizador através de um PIN, segredo do dispositivo, dados biométricos ou outro método suportado.

Um dado biométrico local normalmente desbloqueia o uso da credencial; o modelo biométrico não é enviado para o website como o segredo de autenticação.

4. O autenticador cria um par de chaves

O autenticador cria um par de chaves de credencial delimitado à parte de confiança. A chave privada permanece protegida pelo autenticador ou pela 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 atestação de acordo com o formato selecionado.

5. O servidor valida e armazena a credencial

A parte de confiança valida a cerimónia antes de armazenar qualquer coisa. As verificações incluem:

• desafio esperado;
• origem esperada;
• hash do identificador da parte de confiança correto;
• estado de origem cruzada esperado e topOrigin quando a cerimónia está incorporada;
• sinalizadores de presença do utilizador e verificação do utilizador de acordo com a política;
• algoritmo e parâmetros de chave aceites;
• estrutura de atestação e política de confiança se a atestação for solicitada;
• unicidade e associação à conta de utilizador 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. Nunca precisa da chave privada.

Como funciona a autenticação FIDO2

A autenticação prova o controlo de uma credencial previamente registada.

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

A parte de confiança gera um novo desafio e envia opções de asserção. Pode incluir uma lista de permissões de identificadores de credenciais ou usar credenciais detetáveis para que o autenticador possa identificar a conta.

2. O cliente solicita uma asserção

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

3. O autenticador assina os dados da cerimónia

O autenticador assina o novo contexto do desafio e os dados do autenticador usando a chave privada da credencial. Como a credencial é delimitada à parte de confiança, 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 de confiança verifica o desafio esperado, a origem, o hash da parte de confiança, a assinatura com a chave pública armazenada, os sinalizadores necessários, a credencial permitida, a vinculação do utilizador e o contador relevante ou o estado de backup. Só então deve criar ou elevar uma sessão da aplicação.

Cada asserção prova o controlo num determinado momento. A criação de sessões, a proteção de tokens, a reautenticação, a autorização de transações, o logout e a revogação permanecem responsabilidades separadas da aplicação.

Por que o FIDO2 é resistente a phishing

Palavras-passe e códigos de uso único podem ser inseridos num site impostor, que pode retransmiti-los para o serviço real. O FIDO2 usa uma credencial delimitada à parte de confiança 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 utilizador notar uma página enganosa.

A resistência a phishing tem limites:

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

Resistência a ataques de repetição e tratamento de desafios

Uma asserção registada não deve funcionar numa cerimónia posterior porque cada pedido usa um novo desafio. O NIST descreve autenticadores criptográficos que incorporam nonces ou desafios como resistentes a ataques de repetição.

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 imposição de expiração ou validação apenas da assinatura, ignorando a origem e o contexto da parte de confiança.

O servidor deve marcar um desafio consumido atomicamente. Se os pedidos paralelos competirem, apenas uma cerimónia bem-sucedida deve ser capaz de usar esse desafio.

Presença do utilizador e verificação do utilizador

WebAuthn distingue:

• Presença do utilizador (UP): o utilizador realizou uma interação indicando participação.
• Verificação do utilizador (UV): o autenticador verificou localmente o utilizador através de um fator de ativação, como um PIN ou dados biométricos.

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 apenas mostram presença. Os requisitos devem indicar os valores esperados dos sinalizadores, em vez de depender de uma etiqueta de interface, como “Usar Face ID”.

A qualidade da verificação local também varia por autenticador. A parte de confiança pode ter visibilidade limitada sobre a implementação exata de dados biométricos ou PIN para autenticadores fornecidos pelo utilizador, portanto, a política deve ser proporcional à transação e à população de implementação.

Autenticadores de plataforma, itinerantes e entre dispositivos

Autenticadores de plataforma

Estes são integrados com um telemóvel, computador portátil ou sistema operativo. Podem proporcionar uma jornada curta usando o método de desbloqueio local do dispositivo. A desvantagem é a dependência da recuperação de conta da plataforma, segurança do dispositivo e comportamento de sincronização.

Autenticadores itinerantes

Chaves de segurança externas podem ser transportadas entre dispositivos e conectadas através 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 telemóvel próximo para autenticar uma sessão noutro dispositivo. Os mecanismos de transferência e proximidade melhoram a usabilidade, mas adicionam detalhes da interface do utilizador e do modelo de ameaças que devem ser testados em vez de tratados como idênticos à autenticação no mesmo dispositivo.

Suporte várias credenciais por conta. Os utilizadores substituem telemóveis, perdem chaves de segurança, usam dispositivos de trabalho e pessoais, e precisam de uma forma segura de nomear, inspecionar e remover credenciais.

Passkeys vinculadas a dispositivos e sincronizadas

Uma passkey é uma credencial FIDO projetada para login sem palavra-passe. As passkeys podem ser:

• Vinculadas a dispositivos: a chave privada da credencial permanece ligada a um autenticador ou dispositivo gerido.
• Sincronizadas: o material da credencial é encriptado e sincronizado através da rede de um fornecedor para uso em dispositivos elegíveis.

As passkeys 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 sobre autenticadores sincronizáveis permite autenticadores sincronizáveis em contextos até ao Nível de Garantia de Autenticação 2 quando os seus requisitos são cumpridos, mas a sincronização entra em conflito com a não exportabilidade exigida no Nível 3.

Não infira garantia da palavra “passkey”. Avalie se as credenciais são suportadas, elegíveis para backup, partilhadas, geridas, vinculadas a dispositivos, atestadas e ativadas com verificação do utilizador de acordo com a política da parte de confiança.

Atestação e confiança do autenticador

A atestação pode fornecer evidências sobre a proveniência ou propriedades de um autenticador no registo. Não é o mesmo que a assinatura de autenticação e não identifica o utilizador humano.

Os serviços de consumo frequentemente minimizam a recolha de atestação para privacidade e compatibilidade com o ecossistema. Implementações de força de trabalho geridas podem exigir modelos de autenticador específicos ou certificação. A decisão deve responder a uma questão do modelo de ameaças, em vez de recolher evidências de identificação do dispositivo por padrão.

Se a atestação for usada:

• defina formatos aceites e âncoras de confiança;
• valide os caminhos e declarações dos certificados corretamente;
• especifique a atualização de metadados e o tratamento da revogação;
• planeie para autenticadores sem atestação de confiança;
• documente as consequências de privacidade e retenção;
• teste a substituição quando um modelo aceite muda de estado.

FIDO2 não substitui a prova de identidade

O FIDO2 prova o controlo de uma credencial registada numa parte de confiança. Não estabelece o nome legal, idade, endereço, estado regulamentar ou unicidade no mundo real da pessoa que a regista.

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

1. Registo pseudónimo: o serviço precisa de uma conta segura, mas não de uma identidade real verificada.
2. Registo vinculado à identidade: a prova de identidade ocorre primeiro, depois uma credencial FIDO é vinculada à conta verificada.
3. Elevação 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. Registe qual conta e estado de prova existiam quando a credencial foi adicionada, qual sessão a autorizou e se o risco posterior deve desencadear reautenticação ou atualização de identidade.

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

A recuperação é onde muitas implementações resistentes a phishing falham. Se um utilizador puder substituir cada credencial FIDO usando um link de email ou perguntas de suporte fracas, um atacante visará esse caminho.

Um ciclo de vida completo abrange:

• adicionar um segundo autenticador;
• nomear e visualizar credenciais registadas;
• perda de dispositivo e suspeita de comprometimento;
• revogar uma credencial sem destruir a conta;
• recuperar com códigos, outro autenticador, suporte gerido ou prova de identidade;
• notificar o utilizador através de um canal independente;
• atrasar ou limitar ações de alto risco após a recuperação;
• registar quem alterou o conjunto de credenciais e porquê;
• encerrar sessões criadas antes de o comprometimento ser comunicado.

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

Como avaliar uma implementação FIDO2

Validação do protocolo

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

Cobertura do autenticador

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

Segurança de conta e sessão

Reveja quem pode adicionar uma credencial, se é necessária autenticação recente, 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 a perda, dispositivos roubados, email comprometido, troca de SIM, representação de suporte e acesso malicioso em casa ou no local de trabalho. Meça tanto a resistência do atacante quanto a conclusão do utilizador genuíno.

Privacidade e observabilidade

Minimize a atestação e os dados do dispositivo para o que a política precisa. Evite usar identificadores de credenciais estáveis em diferentes partes de confiança; a delimitação do WebAuthn foi projetada para evitar isso. Registe os motivos e os resultados da cerimónia sem vazar dados confidenciais do cliente.

Erros comuns na implementação do FIDO2

Verificar a assinatura, mas não o contexto

Uma assinatura válida é insuficiente se o servidor não conseguir verificar o desafio, a origem, o identificador da parte de confiança, os sinalizadores e a vinculação da conta com precisão.

Chamar toda a passkey de multifator

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

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 utilizador e registe o evento.

Suportar apenas uma credencial

Contas com uma única credencial criam uma recuperação frágil e incentivam retrocessos mais fracos. Permita múltiplos autenticadores com gestão e revogação claras.

Deixar a palavra-passe como um recurso equivalente

Se uma palavra-passe puder sempre contornar o caminho FIDO, a resistência a phishing pode existir apenas no botão preferido. Restrinja ou remova caminhos mais fracos de acordo com o risco e a fase de migração.

Ignorar sessões do servidor

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

Uma lista de verificação de implementaçã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 de confiança, 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 suportado;
• os utilizadores podem registar várias 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 recolha de atestação tem uma política definida de confiança, privacidade e metadados;
• os recursos de palavra-passe, código de uso único, suporte e recuperação de identidade são modelados em termos de ameaças;
• as sessões autenticadas e a autorização de transação são protegidas separadamente;
• as bibliotecas de protocolo, o suporte do navegador, as depreciações e os eventos de segurança têm responsáveis.

Onde a Didit se encaixa ao lado do FIDO2

O FIDO2 lida com a autenticação após o registo de uma credencial. A Didit pode apoiar a decisão de identidade adjacente através da Verificação de Identidade, Deteção de Vivacidade e Autenticação Biométrica. O preço publicado da Autenticação Biométrica é de $0.10 por verificação.

As equipas podem rever 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 aplicações são decisões de confiança diferentes.

Perguntas frequentes

O que significa FIDO2?

FIDO refere-se a 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 do cliente e da parte de confiança e o modelo de dados. FIDO2 inclui WebAuthn mais CTAP, que conecta a plataforma cliente com autenticadores itinerantes.

As passkeys são credenciais FIDO2?

Sim. As passkeys são credenciais FIDO detetáveis projetadas para login sem palavra-passe. Podem ser sincronizadas entre dispositivos elegíveis ou permanecer vinculadas a um dispositivo.

FIDO2 é resistente a phishing?

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

O FIDO2 usa dados biométricos?

Pode usar um dado biométrico local para ativar um autenticador e definir a verificação do utilizador. A parte de confiança normalmente recebe o resultado e a asserção criptográfica, não o modelo biométrico.

O FIDO2 verifica a identidade de uma pessoa?

Não. Ele verifica o controlo de uma credencial registada. A prova de identidade no mundo real é uma decisão de registo ou recuperação separada quando o serviço o exige.

O que acontece quando um utilizador 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 registado, códigos de recuperação, recuperação administrativa gerida ou prova de identidade renovada, com notificação e restrições pós-recuperação.

Referências primárias

• Especificações de Autenticação de Utilizador da FIDO Alliance
• Rascunho da Recomendação Candidata ao Nível 3 de Autenticação Web do W3C
• Padrão Proposto CTAP 2.3 da FIDO Alliance
• NIST SP 800-63B-4: Gestão de Autenticação e Autenticadores
• Requisitos do autenticador NIST SP 800-63B-4

O FIDO2 substitui segredos de verificador reutilizáveis por credenciais de chave pública delimitadas e novas cerimónias criptográficas. O seu valor sobrevive apenas quando a parte de confiança valida o contexto completo, gere 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 o login.