Be an admin on an up-to-date Discourse site with one or more two-factor keys enabled, such as security keys and authenticator app.
Be able to log in and out successfully with those two-factor keys.
Ensure that the site setting for enforcing two-factor logins is set to “no”.
Delete all of the two-factor items from your (admin) account using the standard UI tools in the Security tab of the admin’s user profile preferences.
Log out.
Expected behavior
Log in to site with username or password; access granted; or
Log in to site with “email me a link”; access granted.
Actual behavior
Both “expected” scenarios fail with an error message, and login is not allowed:
The selected two-factor method is not enabled for your account.
There is no further way to log in with the admin’s account.
It is worth noting that I am not actually locked out of the site in question; I had another session still active on another computer and was able to go over to that session and re-add a token-based authenticator to get back in. However, had I not had another session I would have been “fully” locked out.
Thanks for reporting this. I’ve had it bookmarked for the past few days, but haven’t got around to testing it yet. I assume that what you’re reporting is correct, but will take a close look at it next week.
I guess this is the bug? We should not allow that if your site setting says that all admins must have 2fa enabled.
I think you are not fully locked out, you can use the console to recover now, but we should not make it easy for you to create a pathological situation.
I’m not quite sure that’s the right logic? I didn’t have enforce second factor on anything but the default value of “no” and it’s not really safe to assume that every installation has more than one admin account. It seems that once the 2FA keys are removed from the profile, some other flag is not being removed somewhere…
I think you are not fully locked out, you can use the console to recover now
I suppose this is a valid emergency workaround although it may be beyond the skills of an admin who does not also manage their server and they might have to track down a sysadmin.
SE o usuário não tiver permissão para fazer login novamente após excluir este 2FA (último 2FA que eles têm e o 2FA é necessário para a conta de acordo com as configurações de nível de confiança / configurações do administrador)
ENTÃO não permita que eles excluam o último 2FA e exiba um erro.
Acho que fui atingido pelo mesmo bug (Discourse versão 2.7.10, atualizado hoje).
Recebi direitos de administrador e ativei a 2FA. Mais tarde, criei um segundo usuário para mim a partir de um e-mail diferente para ser usado exclusivamente para administração e concedi direitos de administrador a ele.
Em seguida, removi os direitos de administrador do meu usuário original e excluí todos os métodos de 2FA. Agora, meu usuário original recebe o comportamento de erro mencionado pelo OP.
Não tenho acesso ao console deste servidor. O site não está exigindo 2FA para administradores.
Alguém poderia detalhar exatamente o que precisa ser feito no console para resolver este problema.
Aliás, os motivos pelos quais fiz isso são que quero estar sujeito às permissões e notificações normais (ou não) para grupos privados no site através do meu usuário normal, talvez com o modo de lista de e-mails ativo. Não preciso do atrito extra da 2FA como um usuário comum.
Claro, o usuário administrador pode ver tudo, então é uma questão de confiança que ele não espione desnecessariamente. Esse usuário pode deixar todas as notificações desativadas e não ativar o modo de lista de e-mails.
@sam Você diz tentadoramente que este problema pode ser resolvido pelo console, sem dizer o que especificamente precisa ser feito. Eu realmente apreciaria uma dica sobre como corrigir este problema em particular.
Suspeito que não, pois a conta já tem 2FA desativado, ou para ser mais preciso, removeu todos os métodos de 2FA da conta (2FA aparece como “não” no perfil), mas de alguma forma o login ainda está tentando usar 2FA.
Esse guia é para um usuário que tem 2FA ativado, mas perdeu/esqueceu seus meios de gerar um token válido.
SOLUÇÃO: Como usuário administrador, visite a página de detalhes do usuário bloqueado, role até o final e clique no botão vermelho Impersonate (Simular).
Em seguida, nas preferências do usuário, adicione um método de 2FA. (é necessário ter a senha do usuário para fazer isso)
O segredo de 2FA deve ser fornecido ao usuário bloqueado.
Neste caso, sou ambos os usuários, então não é uma tarefa difícil
A remoção da 2FA pressionando o botão Desativar Tudo se comporta de forma diferente da remoção do último método de 2FA? Ou seja, pressionar esse botão o remove sem bloquear o acesso?
Consegui reproduzir isso e encontrei uma solução usando o console.
O repro é ligeiramente diferente de como é descrito na primeira postagem. O passo 2 é crucial, os passos 3 e 4 são menos importantes.
Seja um usuário admin em um site Discourse atualizado com uma ou mais chaves de autenticação de dois fatores habilitadas, como chaves de segurança e aplicativo autenticador.
Habilite os códigos de backup
Seja capaz de fazer login e logout com sucesso com essas chaves de autenticação de dois fatores.
Certifique-se de que a configuração do site para impor logins de dois fatores esteja definida como “não”.
Exclua todos os itens de dois fatores (autenticadores e chaves de segurança) da sua conta de admin usando as ferramentas padrão da interface na aba Segurança das preferências do perfil do usuário admin.
Faça logout.
O que acontece é que, se todos os itens de dois fatores foram removidos, os códigos de backup ainda estão presentes no banco de dados, e a autenticação de dois fatores não é vista como desabilitada no login.
Como não há mais autenticador ou chave de segurança, o usuário não consegue usar os códigos de backup.
Uma vez que todos os autenticadores e chaves foram removidos, os códigos de backup nem sequer podem ser removidos em Perfil - Segurança.
Correção proposta: Quando o último item de segurança for removido do usuário, os códigos de backup também devem ser removidos.
Solução alternativa: remova todos os registros UserSecondFactor para este usuário do banco de dados.
É possível que uma correção seja implementada para isso em uma versão mais recente do Discourse? Acabei de ter exatamente isso acontecendo comigo hoje e foi uma dor de cabeça para recuperar minha conta.
Tenho o mesmo problema com um usuário reclamando que não consegue fazer login. Este usuário teve o 2FA habilitado em sua conta em algum momento, mas depois o removeu. A mensagem de erro que ele recebe ao tentar fazer login é:
O método de dois fatores selecionado não está habilitado para sua conta.
No menu de administração, vejo que o perfil do usuário lista “Autenticação de Dois Fatores” como “Não”.
Como é má prática pedir a senha do usuário, tentei mudar o e-mail dele ou adicionar um e-mail secundário que eu controlo. No entanto, após clicar em “Confirmar” no URL do e-mail de confirmação, recebo este erro:
O método de dois fatores selecionado é inválido.
… e o e-mail não é alterado/adicionado.
Eu não tenho acesso ao console ou banco de dados para esta instalação do Discord porque é “gerenciada”.
Há mais alguma coisa que eu possa tentar? Ou o usuário está bloqueado de sua conta para sempre?
Não tenho acesso ao console do discourse, pois esta é uma instância do discourse “hospedada”.
Os administradores precisam ser capazes de limpar a fábrica de 2FA (autenticação de dois fatores) na interface de administração, é extremamente pouco profissional ter que pedir as senhas dos nossos usuários.
Este é claramente um bug importante que precisa ser resolvido. Como podemos relatar formalmente isso e acompanhar o progresso de correção de bugs?
Como um projeto OpenSource com uma instância do discourse hospedada, não consigo acessar o console ou o banco de dados, tenho apenas a interface de administração.
Na verdade, discordo. Quando o 2FA (autenticação de dois fatores) é desativado, os códigos de backup do 2FA (autenticação de dois fatores) devem ser completamente ignorados e não importar em nada.
Ao corrigir isso no lugar errado (quando o último método de 2FA é removido, remova os códigos de backup), ainda temos pessoas que não conseguem fazer login e simplesmente desistiram sem relatar.
Ao corrigir o bug real (considerando os códigos de backup quando o 2FA está desativado), corrigimos isso para 100% dos usuários impactados, imediatamente, em vez de apenas garantir que isso não continue acontecendo com novos usuários.
Você não deve desabilitar o 2FA diretamente, você deve primeiro:
remover todos os códigos de backup de 2FA
verificar triplamente se todos os códigos de backup de 2FA foram removidos
somente então desabilitar o 2FA
Usando este método, você realmente consegue desabilitar o 2FA. Isso é verdade tanto para usuários administradores que simulam usuários para corrigir isso, quanto para qualquer usuário normal que apenas queira desabilitar o 2FA.
