WebAuthn
# WebAuthn

Autenticação da Web (WebAuthn) é um padrão da web publicado pelo World Wide Web Consortium (W3C). WebAuthn é um componente central do Projeto FIDO2 sob a orientação da FIDO Alliance. O objetivo do projeto é padronizar uma interface para autenticação de usuários em aplicativos e serviços baseados na web usando criptografia de chave pública. As credenciais WebAuthn (que são credenciais FIDO) que estão disponíveis em vários dispositivos são comumente chamadas de chaves de acesso.
No lado do cliente, o suporte ao WebAuthn pode ser implementado de várias maneiras. As operações criptográficas subjacentes são executadas por um autenticador, que é um modelo funcional abstrato que é amplamente independente de como o material da chave é gerenciado. Isso permite que o suporte ao WebAuthn seja implementado puramente em software, usando o ambiente de execução confiável de um processador ou de um Trusted Platform Module (TPM). Operações criptográficas confidenciais também podem ser transferidas para autenticadores de hardware de roaming acessados ​​por USB, Bluetooth Low Energy ou comunicações de campo próximo (NFC). Os autenticadores de hardware de roaming está em conformidade com o Protocolo FIDO Cliente para Autenticador (CTAP), tornando o WebAuthn efetivamente compatível com o padrão FIDO Universal 2nd Factor (U2F).
Tal como o U2F legado, a autenticação Web é resiliente à representação do verificador; ou seja, é resistente a ataques de phishing, mas, ao contrário do U2F, o WebAuthn não requer uma palavra-passe tradicional. Além disso, um autenticador de hardware itinerante é resistente a malware, já que o material da chave privada não fica acessível em nenhum momento ao software em execução na máquina host.$^[$
Os níveis padrões WebAuthn 1 e 2 foram publicados como Recomendações W3C em 4 de março de 2019 e 8 de abril de 2021, respectivamente. Uma especificação de Nível 3 é atualmente um First Public Working Draft (FPWD).

## Contexto

FIDO2 é o sucessor do FIDO Universal 2nd Factor (U2F). Enquanto o U2F suporta apenas o modo multifator, tendo sido projetado para fortalecer os fluxos de login existentes baseados em nome de usuário/senha, o FIDO2 adiciona suporte ao modo de fator único. No modo multifator, o autenticador é ativado por um teste de presença do usuário, que geralmente consiste em um simples toque de botão; não é necessária senha. No modo de fator único, o autenticador (algo que você tem) realiza a verificação do usuário. Dependendo das capacidades do autenticador, isso pode ser:
* algo que você sabe: um segredo como um PIN, senha ou padrão de furto
* algo que você é: uma biometria como impressão digital, íris ou voz
Independentemente do modo, o autenticador nunca compartilha seus segredos ou dados biométricos com o site. Além disso, um único segredo de usuário ou biometria funciona com todos os sites, pois o autenticador selecionará o material de chave criptográfica correto para usar no serviço que solicita autenticação após a verificação do usuário ser concluída com sucesso.$^[$

## Visão geral

Tal como o seu antecessor FIDO U2F, a autenticação Web W3C (WebAuthn) envolve um site, um navegador web e um autenticador:
* O site é uma parte confiável do WebAuthn em conformidade
* O navegador é um cliente WebAuthn em conformidade
* O autenticador é um autenticador FIDO2, ou seja, presume-se que seja compatível com o WebAuthn Client

### Autenticação

Para fins de ilustração, assumimos que o autenticador é um autenticador de hardware em roaming (veja abaixo outras opções). Em qualquer caso, o autenticador é um autenticador criptográfico multifator que usa criptografia de chave pública para assinar uma declaração de autenticação direcionada à Parte Confiável do WebAuthn. Supondo que o autenticador use um PIN para verificação do usuário, o autenticador em si é algo que você tem, enquanto o PIN é algo que você conhece.$^[$
Para iniciar o fluxo de autenticação WebAuthn, a Parte Confiável do WebAuthn indica suas intenções ao Cliente WebAuthn (ou seja, o navegador) via JavaScript. O cliente WebAuthn se comunica com o autenticador usando uma API JavaScript implementada no navegador. Um autenticador de roaming está em conformidade com o Protocolo FIDO Cliente para Autenticador.$^[$
O WebAuthn não exige estritamente um autenticador de hardware de roaming. Como alternativa, um autenticador de software (por exemplo, implementado em um smartphone) ou um autenticador de plataforma (ou seja, um autenticador implementado diretamente no dispositivo cliente WebAuthn) pode ser usado. Exemplos relevantes de autenticadores de plataforma incluem o Windows Hello e o sistema operacional Android.
O fluxo ilustrado depende da verificação do usuário baseada em PIN, o que, em termos de usabilidade, é apenas uma melhoria modesta em relação à autenticação de senha comum. Na prática, o uso de biometria para verificação de usuários pode melhorar a usabilidade do WebAuthn. No entanto, a logística por trás da biometria ainda é pouco compreendida. Existe um mal-entendido persistente entre os utilizadores de que os dados biométricos são transmitidos pela rede da mesma forma que as palavras-passe, o que não é o caso.

### Registro

Quando o Parte Confiável do WebAuthn recebe a declaração de autenticação assinada do navegador, a assinatura digital na declaração é verificada usando uma chave pública confiável para o usuário.$^[$
Para obter uma chave pública para o usuário, a Parte Confiável do WebAuthn inicia um fluxo de registro WebAuthn que é semelhante ao fluxo de autenticação ilustrado acima. A principal diferença é que o autenticador agora assina uma declaração de atestado com sua chave privada de atestado. A declaração de atestado assinada contém uma cópia da chave pública que a Parte Confiável do WebAuthn usa para verificar uma declaração de autenticação assinada. A declaração de atestado também contém metadados que descrevem o próprio autenticador.$^[$
A assinatura digital na declaração de atestado é verificada com a chave pública de atestado confiável para aquele modelo específico de autenticador. Não foi especificado como a Parte Confiável do WebAuthn obtém seu estoque de chaves públicas de atestado confiáveis. Uma opção é usar o serviço de metadados FIDO.

## Suporte

O nível padrão WebAuthn 1 foi publicado como uma Recomendação W3C pelo Grupo de Trabalho de Autenticação da Web em 4 de março de 2019. O WebAuthn é suportado pelo Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari e Opera.
A versão desktop do Google Chrome oferece suporte ao WebAuthn desde a versão 67. O Firefox, que não suportava totalmente o padrão FIDO U2F anterior, incluiu e habilitou o WebAuthn na versão 60 do Firefox, lançada em 9 de maio de 2018. Uma versão inicial do Windows Insider do Microsoft Edge (Build 17682) implementou uma versão do WebAuthn que funciona tanto com o Windows Hello quanto com chaves de segurança externas.
As chaves de segurança FIDO U2F existentes são amplamente compatíveis com o padrão WebAuthn, embora o WebAuthn tenha adicionado a capacidade de referenciar um identificador de "identificador de usuário" exclusivo por conta, que os autenticadores mais antigos não conseguem armazenar.
Um dos primeiros autenticadores compatíveis com FIDO2 foi a Chave de Segurança de segunda geração da Yubico, anunciada em 10 de abril de 2018. O primeiro autenticador compatível com FIDO2 com display foi o Trezor Modelo T da SatoshiLabs, anunciado em 6 de novembro de 2019. O Trezor Modelo T também foi o primeiro autenticador que permitiu aos usuários selecionar qual credencial de residente FIDO2 deveria ser usada diretamente em um dispositivo.
A primeira chave FIDO2 certificada como Nível de Segurança 2, chamada "Goldengate", foi anunciada um ano depois pela eWBM em 8 de abril de 2019.
A Apple anunciou que o Face ID ou Touch ID poderia ser usado como um autenticador de plataforma WebAuthn com o Safari em 24 de junho de 2020.

## Recepção

Em agosto de 2018, a Paragon Initiative Enterprises conduziu uma auditoria de segurança do padrão WebAuthn. Embora não tenham conseguido encontrar nenhuma exploração específica, eles revelaram algumas fraquezas sérias na forma como a criptografia subjacente é usada e exigida pelo padrão.
A Paragon Initiative Enterprises também criticou como o padrão foi desenvolvido inicialmente, já que a proposta não foi tornada pública com antecedência e criptógrafos experientes não foram solicitados a dar sugestões e feedback. Portanto, o padrão não foi sujeito a ampla pesquisa criptográfica do mundo acadêmico.$^[$
Apesar dessas deficiências, a Paragon Initiative Enterprises ainda incentiva os usuários a continuarem usando o WebAuthn, mas apresentou algumas recomendações para possíveis implementadores e desenvolvedores do padrão que eles esperam que possam ser implementadas antes que o padrão seja finalizado. Evitar tais erros o mais cedo possível protegeria a indústria de quaisquer desafios introduzidos por padrões quebrados e pela necessidade de compatibilidade com versões anteriores.$^[$
O ECDAA foi projetado apenas para ser usado em combinação com a certificação de dispositivos. Esse recurso específico do WebAuthn não é necessariamente necessário para que a autenticação funcione. As implementações atuais permitem que o usuário decida se uma declaração de atestado será enviada durante a cerimônia de registro. Independentemente, as partes confiáveis podem escolher exigir ou não atestado. O ECDAA foi removido do WebAuthn Nível 2 porque não foi implementado pelos navegadores nem pelas partes confiáveis.