Suporte ao Webauthn

Contribuir Funcionalidade
1

RFC WebAuthn

Este tópico tem como objetivo documentar as metas do projeto Discourse em torno da autenticação FIDO2 / WebAuthn.

Por quê?

Adicionar suporte ao WebAuthn no Discourse aumentará a segurança das contas de usuário, permitindo contas sem senha facilmente acessíveis usando os recursos seguros de seus dispositivos, como um leitor de impressão digital de smartphone.

Métodos de Autenticação

  • WebAuthn como autenticador de segundo fator (atuando como uma alternativa ao Google Authenticator)
  • WebAuthn como autenticador de primeiro fator (atuando como uma alternativa ao login social)
  • WebAuthn como autenticador de múltiplos fatores (login sem nome de usuário)

WebAuthn como autenticador de segundo fator

Isso permitirá que um usuário do Discourse, que já possui uma conta ativa, use o WebAuthn como 2FA, onde hoje só suportamos TOTP.

Qualquer método WebAuthn pode funcionar aqui, seja biometria do dispositivo (sensor de impressão digital no Android, Windows Hello em laptops), um chip seguro do dispositivo (TPM, enclave seguro) ou uma chave de hardware (como um Yubikey).

Isso estaria disponível para todos os usuários que navegam com:

  • Microsoft Edge no Windows, usando Windows Hello (com reconhecimento facial, leitor de impressão digital ou PIN)
  • Chrome no macOS, usando Touch ID
  • Telefone Android
  • Laptop/Desktop/Telefone + Chave Física (Yubikey, Google Titan)

webauthn-2fa-mockup
webauthn-2fa-mockup1791×1268 131 KB

WebAuthn como autenticador de primeiro fator (contas sem senha)

Permite que um usuário faça login em sua conta do Discourse usando a autenticação WebAuthn como alternativa a uma senha. Se um autenticador de primeiro fator for configurado, o usuário será solicitado a usar o autenticador em vez de uma senha.

Os mesmos métodos de autenticação para autenticação de segundo fator funcionarão para autenticação de primeiro fator: biometria, chip seguro ou chave de hardware.

Fluxo de Registro

image
image507×583 27.2 KB

image
image474×492 16.5 KB

Sem campo de senha

image
image425×152 7.65 KB

Fluxo de Login

860×793 42.8 KB

580×456 14.9 KB

421×150 7.82 KB

WebAuthn como autenticador de múltiplos fatores (logins sem nome de usuário)

Exporá um método de login alternativo que solicita apenas entrada WebAuthn. A chave de segurança registrada passará adicionalmente informações de ID de usuário para o servidor do Discourse.

Este método de autenticação atualmente requer uma chave de autenticação moderna (por exemplo, um Yubikey 5) mais o Google Chrome 76+, pois depende de um recurso chamado “Chaves Residentes”. Como isso armazena dados no autenticador, podem haver limitações; por exemplo, o Yubikey 5C pode armazenar no máximo 25 deles.

Fluxo de Registro

Esses fluxos são uma evolução do fluxo para logins sem senha, não um fluxo de login separado. Isso permite uma implementação iterativa.

image
image507×583 27.2 KB

image
image478×536 20.7 KB

Sem campo de senha, adiciona uma caixa de seleção extra para uso de chaves residentes

image
image425×152 7.65 KB

Fluxo de Login

860×793 42.8 KB

image
image367×305 10.5 KB

Se o nome de usuário for deixado em branco, tentaremos buscar um user_id no autenticador

421×150 7.82 KB

Referências

Demonstrações

https://webauthndemo.appspot.com/

https://webauthn.io/dashboard

Recursos

https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285

22 curtidas
Webauthn as first-factor
Discourse 2.4.0.beta6 Release Notes
Yubikey/U2F Key Support
Support passwordless login with Passkeys
Publishing DB backups without exposing users private information
2

Obrigado por este RFC, ele é bastante completo! Porém, tive uma ideia sobre o fluxo de uso do WebAuthn como método de autenticação de dois fatores (2FA) junto ao login normal com nome de usuário e senha. Quando uso 2FA com TOTP, aparece este modal ao fazer login:

image
image405×271 8.67 KB

Se um usuário tiver tanto códigos TOTP quanto autenticadores WebAuthn habilitados, qual seria o fluxo? O usuário decidiria neste modal se deseja usar WebAuthn ou seu token 2FA? Ou isso seria muito trabalhoso? Talvez o Discourse pudesse, por padrão, solicitar WebAuthn se o usuário tiver configurado e o navegador oferecer suporte, e depois recorrer ao 2FA?

Implementações Existentes

Twitter:

image
image601×287 6.73 KB

image
image613×329 11.1 KB

image
image613×313 13.8 KB

Github:

image
image707×133 7.31 KB

image
image733×313 12.9 KB

Conta Google:

image
image677×809 48.9 KB

image
image685×813 21.6 KB

image
image683×733 23 KB

6 curtidas
3

Sim, isso parece estar se tornando a maneira padrão de implementar o WebAuthn, e eu gosto bastante desse fluxo de login. Definitivamente, acredito que seguiremos nessa direção aqui também.

7 curtidas
4

Obrigado, Jeff, faz sentido. Algumas outras reflexões hoje, após mais investigação:

Autenticação de Primeiro Fator

  • Se um usuário se cadastrar em uma conta do Discourse usando o Webauthn como método de autenticação de primeiro fator, existiria uma maneira posterior de ele mudar para usar uma senha? E, em caso afirmativo, a autenticação Webauthn configurada passaria a funcionar como um método de 2FA regular, até que o momento em que o usuário desejar removê-la?
  • Se o Webauthn foi usado como método de primeiro fator, ele ainda apareceria na interface do usuário nas preferências de segundo fator, apenas sem a opção de remoção?
  • Seria correto afirmar também que o usuário ficaria impedido de configurar logins sociais da mesma forma que é impedido quando o 2FA está habilitado?
  • Imagino que a seção das preferências do usuário onde o e-mail de redefinição de senha é enviado também mudaria, já que eles não teriam uma senha ao usar o primeiro fator:

image
image579×174 6.88 KB

6 curtidas
5

Em termos de texto, não gosto de usar o termo “WebAuthn”; acho que pode confundir os usuários finais. Use apenas “Chave de Segurança” ou algo similar.

Gostaria muito de evitar pensar em “primeiro fator / autenticação sem senha” aqui. Para mim, precisamos lançar esse recurso e conviver com ele por 3 a 4 meses antes mesmo de considerar essa questão.

Especialmente porque já suportamos login por e-mail, então, tecnicamente, o usuário pode esquecer a senha.

Concordo que o fluxo deve ser o seguinte: se possível, houver APIs disponíveis e uma chave WebAuthn, tente a WebAuthn primeiro, mas ofereça uma saída ao usuário. Além disso, lembre-se de que o usuário pode ter vários dispositivos WebAuthn; sugiro seguir o que o Google faz aqui para lidar com isso (um link “Escolher outra opção” ou algo similar).

Uma coisa que penso a longo prazo, em um item separado, é que poderíamos usar o “aplicativo Discourse” para 2FA, o que seria bem legal, @pmusaraj. Isso tornaria o uso da 2FA muito mais ubíquo.

14 curtidas
Support passwordless login with Passkeys
6

Sim, concordo. O termo “webauthn” nos mockups é apenas um espaço reservado.

Dito isso, “Chave de Segurança” não transmite o fato de que o usuário pode usar a impressão digital ou a câmera do laptop/celular.

Sim, os 3 métodos apresentados devem ser implementados nessa ordem, já que o 1 é um pouco mais simples, mas estabelece a base para os métodos 2 e 3.

6 curtidas
7

O GitHub está na mesma página também:

image
image367×488 15.3 KB

8 curtidas
8

Quanto ao “WebAuthn como autenticador de primeiro fator”, há uma discussão sobre a inclusão, no nível 2 do padrão, das implicações de privacidade que isso pode ter: https://github.com/w3c/webauthn/pull/1250/

Quanto à nomeação de chaves de segurança, concordo pelos motivos expostos na PR do RubyGems.org.

Também sugeri lá adicionar um carimbo de data/hora de “último uso para login” além do apelido da chave de segurança, para ajudar a diferenciá-las e identificar possíveis atividades maliciosas.

8 curtidas
9

No trabalho (que é um contexto de alta segurança), também temos um alerta que envia um e-mail após uma chave de segurança não ser usada por 90 dias, incentivando você a usá-la ou removê-la da sua conta.

Acho que implementar isso aos 360 dias pode ser uma boa ideia?

7 curtidas
10

Ótima ideia. Ter um intervalo menor seria chato, já que usamos sessões “infinitas” e acho que a maioria das pessoas terá uma chave diária mais uma de backup guardada na gaveta. Sem contar as chaves de segurança nativas de vários dispositivos.

6 curtidas
11

Tenho o prazer de anunciar que acabei de mesclar o PR para este recurso, então poderemos testar o WebAuthn muito, muito em breve! :tada:

8 curtidas
12

Acabei de adicionar minha impressão digital Android, Yubikey via NFC e Yubikey via USB-C, usando o Chrome no Android e o Firefox no Desktop, e tudo parece estar correto até agora.

Screenshot_20191002-000411
Screenshot_20191002-0004111080×2160 106 KB

Grande bug @Martin_Brennan @featheredtoast, não há como fazer login na visualização para celular:

Screenshot_20191002-001000
Screenshot_20191002-0010001080×2160 212 KB

Funciona perfeitamente na visualização para Desktop:

Screenshot_20191002-001132
Screenshot_20191002-0011321080×2160 158 KB
Screenshot_20191002-001137
Screenshot_20191002-0011371080×2160 122 KB

10 curtidas
13

Algum feedback aleatório :slight_smile:

Isso não parece correto:

image
image1670×372 17.1 KB

Devemos seguir o Composer aqui em relação à margem e à cor do botão cancelar.

image
image599×120 3.13 KB

Em vez de “E-mail de redefinição de senha”, parece que não pertence aqui.

Que tal algo assim?

Continuar cancelar

Esqueceu a senha? ← em cinza claro

A entrada de senha parece muito grande; deveria ser um pouco menor.

image
image1138×899 51.9 KB

Acho que isso deveria dizer “Remover” ou “Excluir”

Se você tentar adicionar uma Yubikey que já foi adicionada, aparece uma mensagem de erro criptica.

No geral: :+1: :+1: :+1: :confetti_ball:

9 curtidas
14

Argh, eu sabia que estava faltando uma rota na revisão. Boa observação :heart:

Acho que tem sido assim há algum tempo, mas sim, são boas mudanças.

Concordo, boa mudança.

Talvez possamos reutilizar a mensagem padrão do Chrome aqui? “Você já registrou esta chave de segurança. Não é necessário registrá-la novamente.” é uma mensagem clara e objetiva.

9 curtidas
15

Obrigado, @Falco e @sam, pelo feedback. Eu não sabia que havia uma rota diferente para o login móvel também! Vou começar a trabalhar nessas correções, incluindo as alterações nas etiquetas de senha e nos botões, hoje à noite. Espero até abrir um novo PR para corrigir!

7 curtidas
16

Fico muito feliz que isso tenha funcionado no seu Android também (mesmo que a visualização móvel não esteja funcionando corretamente) — eu não tinha um Android para testar.

6 curtidas
17

Posso recomendar o Xiaomi Mi 9?

3 curtidas
18

Não tenho certeza se estou pronto para voltar ao Android – amo demais meu iPhone 8 :sweat_smile:

5 curtidas
19

Aqui está o PR para corrigir o acima :rocket:

6 curtidas
20

Quem disse ‘retornar’? Isso é pensamento do mundo antigo! Pessoas modernas possuem vários dispositivos :wink:

8 curtidas