Two Factor local login proposal

Is this logged in staff logs? I don’t think user enabling/disabling 2factor themselves, but for admin disabling a user’s 2factor we might want to consider logging it.

Awesome work, by the way. Excited to try this out!


Not just yet, though I agree that this should. I’ll add it to my to-do


Remove the red, this is not an error condition. It’s a normal part of the login process.

Codes are generated at a rate of 1 every 30 seconds. Add a 50% buffer, and 3 per minute should be just fine.


Fair enough - Without a banner color, the text looks suspiciously floaty, so I’ll see what I can do about that.

I’d prefer to be more generous with the rate limit, but I don’t mind either way.

Looks like the build is failing due to formatting issues – I’ll be able to implement those changes and fix up the formatting tonight.

1 Like

Are you blocking double login attempts the previously used verification code?

Doing so is a bit of a trade-off because it means that users can only authenticate once every 30 seconds (because they need to wait for a new code), but it prevents an attacker from (immediately) using a token he for some reason saw to open a second session.
My guess is that most websites do that, but I didn’t check. I do know that this check is optional in the google-authenticator Linux PAM module that prompts for these codes when connecting via SSH :slight_smile:

1 Like

Not currently - but it should be a relatively simple change if we wanted to turn that on. The ROTP library supports it natively, so I’d just need to additionally store the last time a specific token was used.


Staff actions now log :white_check_mark:
Changed the login label to be an h3, rather than an error banner :white_check_mark:
Second factor rate limiting dropped down to 3/minute :white_check_mark:
Fixed formatting issues and failing tests :white_check_mark:

I haven’t yet gotten around to tackling the token re-use yet – that will be next on the chopping block.


Not a huge fan of having the title “Google Authenticator”, cause I just feel like this is advertising Google on our user page.

Instead perhaps?

Two-factor authentication

[Enable two factor authentication]

what is two factor authentication?

^^^ when you click that it pops a modal:

Basic spiel about 2fa with links to Google authenticator and FreeOTP

Great work, will be happy to try it out.


Thanks Sam - I agree with that assessment. I’ll change it to be less advertise-y.

To do:

  • Google authenticator - change verbiage to 2 factor with description text.

From review:

  • Add js tests
  • Add controller tests
  • Missed a few translatable texts, move the remaining
  • Refactor and reorganize controllers
  • add ember components to de-duplicate
  • Fix up code formatting

Worked this week at getting up to speed with qunit, and moving forward on most of the review items.


  • Blocking previous codes - valid 2-factor auth tokens can only be authenticated once/30 seconds. :white_check_mark:
    • I played with updating the “last used” any time the token was attempted but that seemed to be overkill, and frustrating as to why a token would fail.
  • Translatable texts. :white_check_mark:
  • Move second factor logic to a helper class. :white_check_mark:
  • Move second factor specific controller endpoints to its own controller. :white_check_mark:
  • Move serialization logic for 2-factor details in admin user views. :white_check_mark:
  • Add a login ember component for de-duplication :white_check_mark:
  • Fix up code formatting :white_check_mark:
  • Change verbiage of google authenticator :white_check_mark:


  • js tests
  • controller tests
  • Add modal for explaining what 2fa with links to Google Authenticator/FreeOTP


For reviewers, would it be easier to squash my changes in a new commit, or have an incremental “since last review” commit? Regardless, I will finish writing the tests and other todo items, and push it back up soon.

For running qunit tests, is there a way of quickly running a single test? As I’m building out a suite, It would be great to be able to build out expectations without having to re-run all tests each time.


It doesn’t matter – whatever suits you best. GitHub has an option to show only changes since last review and we can always squash your commits when we merge the PR.


I’ve finished wiring up the tests this week, so I think I’m ready for the next batch of reviews. Travis (specifically yarnpkg) seems to be having some issue today with setting up some of the tests, so having some difficulty getting that sweet green checkmark sadly.

@sam re: naming conventions, I’d ideally be evolving the user_second_factors table to hold all second factor information, so you can easily parse all second factors via the type column. For this pass, this is a 1-1 relationship to a user with TOTP only, but as we add more this would become a 1-many, as I was following @riking’s suggestion for table structure above. That would allow for uf2, and back up codes all in a single table.


  • Rebased on latest master :white_check_mark:
  • add controller tests :white_check_mark:
    • second factor controller tests
    • change email tests
    • change password tests
    • admin login tests
  • add qunit tests :white_check_mark:
    • password reset
    • preferences
  • Add modal for explaining what 2fa with links to Google Authenticator, Authy, and FreeOTP :white_check_mark:


  • check for 2factor on change email controller :white_check_mark:
  • email controller - only show second factor errors on attempt :white_check_mark:
  • properly check against ‘true’ to enable second factor. :white_check_mark:

i can’t wait for this! great work!

Hm, looks like I’ve got another route to take care of now that sign in via email link is here. Adding that to the to-do.


Alright, I’ve rebased on the latest, and implemented extra second factor check when logging in via email - this is back in working order with the latest version of Discourse.

I also check for the second factor param to determine how to rate limit, rather than check via a session/per IP, which slipped my mind before somehow.

I’ve decided to squash just so further conflicts won’t happen on earlier versions before I split out some of the logic to a separate second factor controller.

All in all, it looks all good and complete from here - Hoping the team finds the work acceptable soon! :slight_smile:


Thanks heaps, the plan is for me, @eviltrout and @tgxworld to review this on Monday, aiming to have it merged in next week.


Merged in

Many thanks to @awole20 for pushing this through.


a much-needed addition and very grateful for it! our community gives you thanks!


Nice feature! Thank you guys.

I‘m just missing the possibility to show the QR Code again, to setup another device (iPad) as backup.

This seems unusual. All sites I’ve ever used TOTP on require all devices to be configured at once (Google, Dropbox, Microsoft, Facebook, LastPass, Amazon…), and do not display the QR code ever again. Do you use TOTP on another system that displays the QR code multiple times?