2FA issue still present on Discourse on Unix.com forum

Mekando · December 26, 2022, 5:25pm

Hi all,

There was one topic on the matter [1] however that issue is not fixed as of today. The issue remains, with the same message:

Invalid authentication code. Each code can only be used once.

Now i have been using other Discourse forums and 2FA works there so is there a chance that something is missing on the forum for 2fa to work?

Thank you in advance.

[1] Issue with two factor authentication on community

Neo · December 27, 2022, 2:35am

There is only one special custom setting for 2FA in Discourse:

There are no other settings:

Fixed: ~~So, there is nothing we can do to help you, sorry.~~ - system clock issue.

Also, at least in my view as a cybersecurity person, there is no real reason (for non staff members) to use 2FA here as there is little risk, as it's just a forum, not a bank account or anything where using 2FA is critical or even important.

So, if you cannot make it work our Discourse forum, @Mekando, there is no risk or loss to you as you are not a staff member with any special privs here.

Regarding other Discourse forums, I have no idea because I do not enable 2FA for forums, sorry; and I don't consider 2FA important for a discussion forum for regular members and so will not spend any time on this, sorry again.

Perhaps someone else....

DiscourseDuck · December 27, 2022, 10:16am

OK.

This is fixed.

It's not a Discourse issue. It was a system clock issue.

I updated the system clock on the server and also updated the system clock on my mac and it worked perfectly.

First Google Search Result

Neo · December 27, 2022, 12:29pm

This is hard coded in the Discourse code, but it should be an admin config setting:

  TOTP_ALLOWED_DRIFT_SECONDS = 30

Did not measure the offset before correcting, because we simply used ntpdate to update the system time on the server, and at the same time, used chrony on the client end, and it worked. Should have recorded the clock skew first, but were just testing for a fix and forgot to record before running both chrony and ntpdate.

See

github.com

discourse/discourse/blob/e313190fdb186e1bc04bdb99eef40d365c23a560/app/models/concerns/second_factor_manager.rb

# frozen_string_literal: true

module SecondFactorManager
  TOTP_ALLOWED_DRIFT_SECONDS = 30

  extend ActiveSupport::Concern

  SecondFactorAuthenticationResult = Struct.new(
    :ok,
    :error,
    :reason,
    :backup_enabled,
    :security_key_enabled,
    :totp_enabled,
    :multiple_second_factor_methods,
    :used_2fa_method,
  )

  def create_totp(opts = {})
    require_rotp

This file has been truncated. show original

Now, we are running ntpdate in the cron to keep the server clock more accurate :). Thanks @Mekando for poking us about this.

Neo · December 27, 2022, 12:48pm

The problem is more of a Discourse issue, not a server issue.

The problem is here in the Discourse code:

  def invalid_totp_or_backup_code_result
    invalid_second_factor_authentication_result(
      I18n.t("login.invalid_second_factor_code"),
      "invalid_second_factor"
    )
  end

If you look at the code a bit deeper you can see that the error message is incorrect when the drift time is exceeded.

If the error message was correct, in this case, something like:

Drift time exceeded.

Instead of:

Each code can only be used once.

Then, the error message would have not been misleading (or in this case, totally wrong), causing confusion for users.

Its a case of poor error message coding / management in the Discourse code base.

Even though the problem is fixed now because the clocks are correct, when clocks are not correct and the hard coded drift time is exceeded (or the user waits too long to enter the TOTP), users will see the wrong error message, as in this case.

Anyway, we cannot complain. Discourse is open source and we are not going to submit a PR to fix these issues:

Incorrect error message.
Hard-coded 30 second drift tolerance value for TOTP.